Gavin Sherry <swm@linuxworld.com.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