Re: pg_restore problems and suggested resolution

Joe Conway <mail(at)joeconway(dot)com> 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 this.

I guess the questions we should ask are:

(1) Is there an argument for having a mechanism that would defeat
triggers/rules in all backends and not just the invoking one?
I find it hard to envision a good case for this --- in general
you'd not know what other backends are doing, and so it seems really
risky to use such a mechanism. Certainly pg_dump doesn't need it.

(2) Is there a need to defeat triggers/rules on just one table?
A SET variable would likely affect all tables. pg_dump wouldn't
care, but what other use-cases are there?

We should also think about what "defeating rules" means exactly.
Defeating ON SELECT rules would render views broken, without offering
any usefulness that I can think of; and for that matter, defeating other
types of rules on a view would result in undesirable behavior (e.g., the
system would then try to insert into the view itself). So I'm inclined
to think that the switch should only disable rules that are attached
to regular tables. Are there any other special cases to be considered?

regards, tom lane