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.
>
> The fact that there's a problem at all is because people are using
> direct poking of the system catalogs instead of some kind of ALTER TABLE
> command to disable/enable triggers; an ALTER command would presumably
> gain exclusive lock on the table and thereby delay until active queries
> finish. But that technique is out there (even in pg_dump files :-() and
> so we'd best try to make the system proof against it.
>
> Any thoughts on which way to go?
I'd say:
1. go with the former
2. we definitely should also have an ALTER command to allow disable/enable of triggers
3. along with the ALTER, document that directly messing with the system catalogs is highly discouraged
Joe
