This is a dead end. The --disable-triggers hack is already a time bomb waiting to happen, because all dump scripts using it will break if we ever change the catalog representations it is hacking. Disabling rules by such methods is no better an idea; it'd double our exposure to compatibility problems. If we're going to do something about this then it needs to be cleaner.
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.
regards, tom lane
I like that idea. I didn't at first, but then I saw the super-user only bit. Where would I start to implement this? Do we want two separate properties for rules and triggers, or one to rule them all?
Joseph
---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
