Why is renaming with legacy_alter_table on dangerous?

Rename with legacy_alter_table on

Warning: it works, but holds the single write lock or breaks the previous release.

What happens

With PRAGMA legacy_alter_table=ON, RENAME TABLE and RENAME COLUMN go back to the pre-3.26 behaviour: references inside views and triggers are not rewritten. The rename succeeds, and the first query through a view that named the old table fails with "no such table".

Why it is dangerous on a populated table

SQLite holds one write lock for the whole database, so anything that rebuilds a table blocks every writer for as long as the copy takes, and that time grows with the table.

Fires on

PRAGMA legacy_alter_table = ON;
ALTER TABLE orders RENAME TO purchases;

The safe pattern

PRAGMA legacy_alter_table = OFF;
ALTER TABLE orders RENAME TO purchases;

Fixtures

The rule ships with these files and the test suite runs them on every change: the first set must fire, the second must stay silent.

PRAGMA legacy_alter_table = 1;
ALTER TABLE orders RENAME COLUMN qty TO quantity;

PRAGMA legacy_alter_table = ON;
ALTER TABLE orders RENAME TO purchases;

PRAGMA legacy_alter_table = OFF;
ALTER TABLE orders RENAME TO purchases;

PRAGMA legacy_alter_table = ON;
PRAGMA legacy_alter_table = OFF;
ALTER TABLE orders RENAME TO purchases;

How to check locally

npx bolvrk check migration.sql --engine=sqlite