Your suggestion of introducing a new command, ALTER TABLE .. DISABLE CONSTRAINT, which can be run by the table owner and paired with a later ALTER TABLE ENABLE CONSTRAINT, is a thoughtful approach. It would allow for more controlled management of constraints while maintaining data integrity.
> Thank you, Laurenz, for your valuable feedback. If the enabling system > trigger doesn’t check the data integrity with the parent table, then this > syntax (ALTER TABLE DISABLE/ENABLE TRIGGER *ALL*) should be removed from > PostgreSQL. Otherwise, it will create confusion for the users.
: Disabling or enabling internally generated constraint triggers requires : superuser privileges; it should be done with caution since of course the : integrity of the constraint cannot be guaranteed if the triggers are not : executed.
There's a reason you were forced to become superuser in order to do this. Anytime you're forced to become superuser, you should take a step back and think carefully what you're doing.
I think it's not a bad idea to suggest that we could have a new command ALTER TABLE .. DISABLE CONSTRAINT, which can be run by the table owner and paired with a later ALTER TABLE ENABLE CONSTRAINT, which verifies the constraint.
-- Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/ "Entristecido, Wutra (canción de Las Barreras) echa a Freyr a rodar y a nosotros al mar"
