Dimitri Fontaine <dimitri@2ndQuadrant.fr> writes:
> Robert Haas <robertmhaas@gmail.com> writes:
>> 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
> What about extensions?
> One use case would be for londiste/slony/bucardo to rewrite the command
> and queue its text, that will be done in C and should probably be done
> first. Using an ANY command trigger means that code will run before user
> specific code (or likewise after it).
Unless you intend a restriction that there be only one ANY trigger,
I don't see how that follows. AFAICS, the only way to guarantee "my
trigger runs first" is to give it a name alphabetically before anything
else in the system.
Also, it strikes me that in most of the trigger ordering cases I've
seen, it's actually more interesting to want to be sure that a
particular trigger runs *last* so that its effects can't be modified
by some other, hypothetically less trusted, trigger.
So I don't think that the mere fact of being an ANY trigger rather than
a command-specific trigger should be taken to mean that a particular
ordering is desirable. Trigger name order isn't the greatest solution
by any means, but it's more flexible than hard-wiring according to
trigger type.
regards, tom lane