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
Andreas Pflug wrote:
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
Joe Conway [EMAIL PROTECTED] writes:
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
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
I've got a custom (-Fc) pg_dump output from a fairly complex 7.2.x db
schema. It has such things as user defined functions, OIDs, rules and
triggers, etc. When I try to restore it to a 7.4 database, it fails
because of some differences in the CREATE TABLE commands (I've got a
column of type
Joseph Tate wrote:
I propose pg_restore --disable-triggers be modified so that triggers are
disabled on the tables that OID fixing is going to UPDATE. I'll
hopefully have a patch against REL7_4_STABLE for this soon, but I
haven't started it yet. Does anyone have any suggestions? Has someone
Joseph Tate [EMAIL PROTECTED] 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
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
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.
