[swsarancodes]

What changed

alter_column with autoIncrement: true on a column that is not an identity column used to be refused ("not compiled: its sequence has to start after the largest existing value"). It now compiles:

• One step, one transaction (inside the lock retry): ALTER TABLE … ADD GENERATED BY DEFAULT AS IDENTITY, then the sequence is started at the largest value the column holds plus one, so a new row cannot be given a number that is already used. BY DEFAULT, so an insert that supplies its own value still works.
• The largest value is read through an index on the column. On a table that is not small the step is refused without one ("add an index first"), because finding the maximum would otherwise read the whole table under the lock.
• The column has to be an integer type and NOT NULL (the same change can make it NOT NULL), a generated column is refused, and a serial column's default has to be removed in the same change (defaultValue: null); the step list then drops the default first.
• The identity's own sequence is the one that is started. pg_get_serial_sequence is ambiguous for a column that still owns the sequence of an old serial default and started the wrong sequence (found by the serial-to-identity scenario below), so the step looks up the sequence the column depends on internally.
• On servers older than PostgreSQL 13, a column that owns an old serial sequence and also has an identity makes every INSERT fail ("more than one owned sequence found"). There the old sequence is detached from the column first (it stays, for anything that calls nextval on it by name), and the step says so.

How it was checked

• 6 new unit tests; the repo suite passes (1,754 tests) and both type-checks are clean.
• Two scenarios in scripts/schema-change-pg.ts: an integer primary key becomes an identity column, and a serial column becomes one. Each inserts a row afterwards and checks it is numbered after the largest value (and that an explicit id still works). Lock levels and the predicted end state are checked like every scenario. npm run test:schema-pg:versions passes on PostgreSQL 12, 13, 14, 15, 16, 17 and 18; the first run caught both the wrong-sequence bug and the PostgreSQL 12 failure above.
• The check that a lock retry that gives up stops no longer depends on how fast the machine is (it failed under heavy load); it still checks that it stops.

Reviewer notes

• Not included: enums, a safe column rename.