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 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 ---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings