Joe Conway wrote:Christopher Kings-Lynne wrote:As an implementation issue, I wonder why these things are hacking permanent on-disk data structures anyway, when what is wanted is only a temporary suspension of triggers/rules within a single backend. Some kind of superuser-only SET variable might be a better idea. It'd not be hard to implement, and it'd be much safer to use since failures wouldn't leave you with bogus catalog contents.
I believe oracle and mssql have ALTER TABLE/DISABLE TRIGGER style statements...
Oracle does for sure, but I can tell you that I have seen people bitten by triggers inadvertantly left disabled before...I think Tom
has a good point.
Might be, but disabled triggers are not only useful when restoring a database. We need this, and supporting this without hacking would be helpful.
I didn't dispute the fact that disabling triggers (without unsupported hacks) is useful. I did agree with Tom that doing so with "permanent" commands is dangerous. I think the superuser-only SET variable idea is the best one I've heard for a way to support this.
Joe
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
