Triggers disabled — with ALL, foreign keys stop being enforced
Warning — this works, but blocks traffic or rewrites data at scale.
What it catches
DISABLE TRIGGER ALL includes the system triggers that enforce foreign keys — writes made while it is off can violate referential integrity permanently, and re-enabling does not re-check them. Disabling a single trigger silently skips whatever logic it carried.
Fires on
ALTER TABLE orders DISABLE TRIGGER ALL;Do this instead
Never DISABLE TRIGGER ALL — it turns off the system triggers that enforce foreign keys, and re-enabling does not re-check rows written meanwhile. If one user trigger must be bypassed, name it, keep the window to a single bounded operation, and re-enable it in the same migration. Better: make the trigger itself cheap or conditional so it never needs disabling.
-- Target one named trigger, re-enable in the same migration:
-- ALTER TABLE orders DISABLE TRIGGER orders_audit_trigger;
-- ... one bounded data fix ...
-- ALTER TABLE orders ENABLE TRIGGER orders_audit_trigger;
-- FK enforcement (system triggers) stays on throughout This rule runs in the hosted service on Startup and above — add --remote with a team token, or use the GitHub Action: npx bolvrk check migration.sql