Unexpected add_index behavior with sqlite

[Jammjammjamm]

I have a migration creating a table. It looks like this (with unnecessary information removed):

create_table :requests do
  column :name, String
  foreign_key :test_session_id, :test_sessions, index: true, type: String
  add_index [:test_session_id, :name], concurrently: true
end

So, I accidently used add_index instead of just index. Sqlite didn't complain about this, and it wasn't until I tried using postgres that I discovered my error:

sequel-5.51.0/lib/sequel/adapters/postgres.rb:156:in `exec': PG::UndefinedObject: ERROR:  type "add_index" does not exist (Sequel::DatabaseError)
LINE 1: ...NCES "test_sessions", "[:test_session_id, :name]" add_index,...

When I dump the schema I can see the problem:

# with add_index
String :"[:test_session_id, :name]"

# after changing to index
index [:test_session_id, :name]

Should the sqlite adapter have been raising an error like the postgres one does? Using add_index instead of index seems like an easy mistake to make.

[jeremyevans]

The sqlite adapter should not be raising an error. add_index is an allowed column type name in SQLite, so SQLite accepts it instead of raising an error. Notice that in the PostgreSQL case, it's not Sequel that is raising the error, it is PostgreSQL (Sequel only wraps the error).

This isn't a bug. It's an consequence of using a method_missing creating columns during schema creation. It makes the happy path slightly nicer, at the expense of hiding bugs in user code.