Re: pg_restore problems and suggested resolution

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