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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
