Inconsistent constraint names in PostgreSQL

Environment

Knex version: 0.95.1 Database + version: PostgreSQL 13 OS: n/a

Bug

Run the code:

  knex.schema.createTable('TestTable', (table) => {
    table.integer('otherId').primary().notNull().references('Other.id');
  }).debug();

It generates the following queries:

[
  {
    sql: 'create table "TestTable" ("otherId" integer not null)',
    bindings: []
  },
  {
    sql: 'alter table "TestTable" add constraint "TestTable_pkey" primary key ("otherId")',
    bindings: []
  },
  {
    sql: 'alter table "TestTable" add constraint "testtable_otherid_foreign" foreign key ("otherId") references "Other" ("id")',
    bindings: []
  }
]

Notice how one constraint name correctly preserves the PascalCase (TestTable_pkey) while the other one ignores it (testtable_otherid_foreign). Knex should be consistent and either always keep the original formatting or always convert it to lower case. I’d definitely prefer the former.

[kibertoad]

@sebastian-nowak I’m mostly concerned that at this point changing logic would be something of a breaking change, because it is possible that someone wrote constraint-manipulating SQL (e. g. for dropping some of the constraints by name) taking the knex behaviour into consideration, and changing observable behaviour outside of semver major is not a good thing to do. And considering that original logic was there at least from 2016, and it didn’t come up until now, I think it’s not that big of an issue for the majority of the users.

[sebastian-nowak]

That’s a good point, it could affect existing migrations. One possible solution is to make the new behavior opt-in in knex config, and it would become enabled by default only when there’s a major release.

And considering that original logic was there at least from 2016, and it didn’t come up until now, I think it’s not that big of an issue for the majority of the users.

I think the majority of users prefer snake case for columns names, so they were not affected. Bigger projects would usually set key and constraint names manually to avoid surprises like this, so they wouldn’t notice it too.