Re: pg_restore problems and suggested resolution

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Joseph Tate <jtate(at)dragonstrider(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: pg_restore problems and suggested resolution
Date: 2004-02-13 23:28:10
Message-ID: 6385.1076714890@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Joseph Tate <jtate(at)dragonstrider(dot)com> writes:
> So now that I've looked at the code, I think that this solution is a
> little too simplistic unfortunately. Now I'm leaning towards
> --diable-rules. Am I correct in thinking that if I change
> pg_class.relhasrules to 'f' that the rules will not be processed?

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2004-02-14 00:04:00 Re: Proposed Query Planner TODO items
Previous Message Edwin S. Ramirez 2004-02-13 22:15:30 Re: Transaction aborts on syntax error.