Tom Lane wrote:
> 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
