[swsarancodes]

What changed

A column rename used to break every query using the old name the moment it ran. For a column of an existing table it now adds a second column and keeps the two in step, so both names work until applications have switched:

1. Expand: ADD COLUMN <new> <same type>, then a BEFORE INSERT OR UPDATE trigger that keeps the two in step in both directions (an insert that gives both keeps the new name's value; an update that changes both keeps the old name's; an insert that gives neither gets the old column's default in both), then the data copied in batches, a check that nothing differs, copies of the plain btree indexes built CONCURRENTLY, and NOT NULL on the new column (through the validated CHECK) if the old one is.
2. Contract (optional, not run by default, destructive): drop the trigger and its function, give the new column the old default (not earlier: two columns with a volatile default would each draw their own value), drop the old column. The indexes on the old column go with it; the copies stay.

Refused, with the way out (compatColumns, default on, turns the whole behaviour off and renames directly, where constraints and views follow the column): a column in a key, a unique constraint, a foreign key or a check; one a view, policy or trigger depends on; a generated or identity column; a partitioned table; and a rename combined with other changes in the same operation. Partial, expression and non-btree indexes are not copied (a warning says so). A table the plan itself creates is renamed directly. The notes say what is not copied (collation, storage settings, statistics targets, comments, column-level grants).

How it was checked

• 5 new unit tests; the repo suite passes (1,765 tests) and both type-checks are clean.
• A scenario in scripts/schema-change-pg.ts runs the rename on a table of a few hundred thousand rows (lock levels of every step against pg_locks and the predicted end state against the catalog, like every scenario), and a new columnrename section exercises the trigger on a real server: existing rows copied, the index copied and valid, the new column NOT NULL, inserts and updates through either name reaching the other, the old default applied to both, an insert that gives both, and then the last step removing the old column, the trigger and its function and leaving the new column with the old default. npm run test:schema-pg:versions (16 sections) passes on PostgreSQL 12, 13, 14, 15, 16, 17 and 18.

Reviewer notes

• This is the last item left on the schema change list; the README's operation list, section count and test commands are updated.