disabled, deferred triggers
От | Neil Conway |
---|---|
Тема | disabled, deferred triggers |
Дата | |
Msg-id | 1040159965.17891.19.camel@tokyo обсуждение исходный текст |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: