Folks,
As you may know, we don't check the tgenabled status of deferred
triggers (e.g. AFTER triggers) -- they are added to the deferred queue
and executed regardless.
This is pretty clearly a bug, but when it's been mentioned before, there
were three possible fixes suggested:
(1) check tgenabled when the trigger is fired (and we're considering
adding it to the deferred event queue)
(2) check tgenabled when the deferred event is activated
(3) check tgenabled at both times -- if #1 AND #2 is true, actually
invoke the deferred trigger
I think we should implement (1), for the following reasons:
- it's simpler: KISS, if nothing else. Adding it to the deferred queue
and then delaying the "is it enabled?" decision to a later point in time
adds complexity for no gain in useful functionality.
- less functional: in theory, someone could twiddle the tgenabled bit
for individual firings of the trigger, to only add some of the firings
of the trigger to the event queue. At the least with the current
implementation of deferred triggers, this wouldn't be possible AFAICS.
Any comments?
If no has a problem with (1), I'll send in a patch implementing it to
-patches.
Cheers,
Neil
--
Neil Conway <neilc@samurai.com> || PGP Key ID: DB3C29FC
