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...
Andres
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
