[CockroachDB] No difference between `integer` and `bigInteger`

Environment

Knex version: 0.95.15+ Database + version: CockroachDB v21.1.13 OS: macOS Monterrey

Bug

Both integer and bigInteger both result in a int8 column being created in CockroachDB, whereas Postgres creates them as int4 and int8 respectively. This becomes an issue, as int8s are always returned as a String by the pg connection library, causing unexpected incompatibilities between the database vendors.

knex.schema.createTable('example', (table) => {
  table.increments();

  table.integer('example_int');
  table.bigInteger('example_bigint');
});

Note how both columns are created as an int8 in CockroachDB.

I believe this is due to the fact that CockroachDB defaults to int8 when using .. ADD COLUMN example INTEGER, which is the default from here (AFAICT as the PG dialect doesn’t have a specific integer in the columncompiler).

[kibertoad]

@nickrum I like that idea, but I wonder how intrusive that would be. Maybe it would be easier to achieve not as an option, but as a separate dialect, extending vanilla cockroachdb one. I would still like to hear @rafiss perspective first, because maybe we would be sabotaging crdb by overriding defaults that might be there for a good reason.

[rijkvanzanten]

What are the implications of current misalignment between pg and crdb? numeric values need to be handled differently?

As of right now, it means that (for CRDB):

• There’s no difference between integer/bigInteger and increments/bigIncrements
• .increments doesn’t actually use auto-incrementing integers, like the name suggests
• All integers are returned as Strings at all times