On Sun, Mar 25, 2012 at 12:15 PM, Andres Freund <andres@2ndquadrant.com> wrote:
> On Friday, March 16, 2012 10:40:46 AM Dimitri Fontaine wrote:
>> > This will have the effect of calling triggers outside of alphabetic
>> > order. I don't think thats a good idea even if one part is ANY and the
>> > other a specific command.
>> > I don't think there is any reason anymore to separate the two? The only
>>
>> > callsite seems to look like:
>> The idea is to have a predictable ordering of command triggers. The code
>> changed in the patch v16 (you pasted code from git in between v15 and
>> v16, I cleaned it up) and is now easier to read:
>>
>> case CMD_TRIGGER_FIRED_BEFORE:
>> whenstr = "BEFORE";
>> procs[0] = cmd->before_any;
>> procs[1] = cmd->before;
>> break;
>>
>> case CMD_TRIGGER_FIRED_AFTER:
>> whenstr = "AFTER";
>> procs[0] = cmd->after;
>> procs[1] = cmd->after_any;
>> break;
>>
>> So it's BEFORE ANY then BEFORE command then AFTER command then AFTER
>> ANY. That's an arbitrary I made and we can easily reconsider. Triggers
>> are called in alphabetical order in each “slot” here.
>>
>> In my mind it makes sense to have ANY triggers around the specific
>> triggers, but it's hard to explain why that feels better.
> I still think this would be a mistake. I don't have a hard time imagining
> usecases where a specific trigger should be called before or after an ANY
> trigger because e.g. it wants to return a more specific error or doesn't want
> to check all preconditions already done by the ANY trigger... All that would
> be precluded by enforcing a strict ordering between ANY and specific triggers.
> I don't see a use-case that would benefit from the current behaviour...
Dimitri's proposed behavior would be advantageous if you have an ANY
trigger that wants to "take over the world" and make sure that nobody
else can run before it. I think, though, that's not a case we want to
cater to - all of this stuff requires superuser privileges anyway, so
we should assume that the DBA knows what he's doing. So +1 for making
it strictly alphabetical, as we do with other triggers. Everything
that can be done under Dimitri's proposal can also be done in that
scheme, but the reverse is not true.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
