Disabling triggers (was Re: pgsql 7.2.3 crash)

Gavin Sherry <swm(at)linuxworld(dot)com(dot)au> writes:
> On Sat, 12 Oct 2002, Joe Conway wrote:
>> Tom Lane wrote:
>>> Hackers: we might reasonably fix this by doing a deep copy of the
>>> relcache's trigger info during initResultRelInfo(); or we could fix it
>>> by getting rid of ri_TrigDesc and re-fetching from the relcache every
>>> time. The former would imply that trigger state would remain unchanged
>>> throughout a query, the latter would try to track currently-committed
>>> trigger behavior. Either way has got pitfalls I think.

>>> Any thoughts on which way to go?

>> I'd say:
>> 1. go with the former

> I agree.

That's my leaning too, after further reflection. Will make it so.

>> 2. we definitely should also have an ALTER command to allow
>> disable/enable of triggers

> I thought this was worked on for 7.3?

Unless I missed it, it's not in current sources.

I was wondering whether an ALTER TABLE command is really the right way
to approach this. If we had an ALTER-type command, presumably the
implication is that its effects would be global to all backends. But
the uses that I've seen for suspending trigger invocations would be
happier with a local, temporary setting that only affects the current
backend. Any thoughts about that?

regards, tom lane