"name order was judged to be more convenient" (multiple triggers)
Jaroslav Záruba
> PostgreSQL uses name order, which was judged to be more convenient.
I have to say that this seems wrong to me.
One of the basic rules in programming/coding is that name of class/
variable/function/etc. should describe its purpose/function/use. Being
forced to adjust name of object to manage its position within some
kind of stack is against this concept. :(
Obviously I can't tell what _exactly_ was meant by "more convenient"
as it depends on context, but from my (user) point of view the time-of-
creation order sounds to be more clear/proper approach, re-creating
triggers in desired order is a matter of seconds.
Best regards
J.Záruba
Laurenz Albe
One convenience aspect clearly is the convenience fo the developers:
Currently the trigger creation time is not stored in the catalogs.
Also, I think it is pretty inconvenient if the trigger firing order
changes if I drop and recreate a trigger...
Alphabetical ordering is a simple rule; if you care about
trigger order, you just follow the rule.
Just for the record, this is how Oracle solves it:
Oracle fires multiple triggers in an unspecified,
random order, if more than one trigger of the same type
exists for a given statement; that is, triggers of the
same type for the same statement are not guaranteed
to fire in any specific order.
(from http://download.oracle.com/docs/cd/B19306_01/server.102/b14220/triggers.htm#sthref3278).
Yours,
Laurenz Albe
Jaroslav Záruba
> Jaroslav Záruba wrote:
> >> SQL specifies that multiple triggers should be fired in time-of-creation order.
> >> PostgreSQL uses name order, which was judged to be more convenient.
>
> > I have to say that this seems wrong to me.
> > One of the basic rules in programming/coding is that name of class/
> > variable/function/etc. should describe its purpose/function/use. Being
> > forced to adjust name of object to manage its position within some
> > kind of stack is against this concept. :(
> > Obviously I can't tell what _exactly_ was meant by "more convenient"
> > as it depends on context, but from my (user) point of view the time-of-
> > creation order sounds to be more clear/proper approach, re-creating
> > triggers in desired order is a matter of seconds.
>
> One convenience aspect clearly is the convenience fo the developers:
> Currently the trigger creation time is not stored in the catalogs.
Aha, that would be it.
> Also, I think it is pretty inconvenient if the trigger firing order
> changes if I drop and recreate a trigger...
Well, as far as I can tell, it just means cut'n'paste times n, where n
is number of your triggers. Maybe I'm just obsessed with proper
naming. :))
But given the creation time does not get stored it is kinda
irrelevant.
> Alphabetical ordering is a simple rule; if you care about
> trigger order, you just follow the rule.
ofcourse :)
>
> Just for the record, this is how Oracle solves it:
> Oracle fires multiple triggers in an unspecified,
> random order, if more than one trigger of the same type
> exists for a given statement; that is, triggers of the
> same type for the same statement are not guaranteed
> to fire in any specific order.
> (fromhttp://download.oracle.com/docs/cd/B19306_01/server.102/b14220/trigge...).
O_o
I love Postgres. :)
> Yours,
> Laurenz Albe
Thanks for the reply!
JZ
Laurenz Albe
>>>> SQL specifies that multiple triggers should be fired in time-of-creation order.
>>>> PostgreSQL uses name order, which was judged to be more convenient.
>>>
>>> I have to say that this seems wrong to me.
>>
>> Currently the trigger creation time is not stored in the catalogs.
>
> Aha, that would be it.
Mind you, it would not be difficult to change that.
It just seems that nobody saw any benefits in that.
I searched the archives and didn't find any discussion.
I guess nobody had a problem with it...
I found the commit message where this was added:
http://archives.postgresql.org/pgsql-committers/2002-04/msg00149.php
It looks like this was a side effect.
Yours,
Laurenz Albe