Re: before trigger doesn't, on insert of too long data

Neil Conway wrote:

> Gaetano Mendola <mendola(at)bigfoot(dot)com> writes:
>
>>I don't know how the check for the data integrity is implemented but if
>>is a trigger
>
>
> It isn't -- trigger firing order is irrelevant to the original
> question.

Well, it is. If the data integrity was done with a system trigger
created at table creation time the firing order is relevant.

>>1) Create table
>>2) create a before insert trigger: trigger_a
>>3) create a before insert trigger: trigger_b
>>
>>test=# insert into test values ( 10 );
>>NOTICE: TRIGGER A
>>NOTICE: TRIGGER B
>>INSERT 3416835 1
>
>
> The firing order of triggers in PostgreSQL is documented: it is done
> alphabetically. When this was discussed, the consensus was that the
> "fire by creation order" part of the spec is not very useful, so we
> decided to deviate from it deliberately.

Good to hear. So, why the standard is there ?
I'm sorry to say that this is a typical MySQL guy response.

Anyway this is my argument against the alphabetic order:

before to create a trigger is reasonable to know that the data
catched by the trigger are the data that I see inserted in the table
when I do an insert. If my aaaaaa trigger is fired before the other
I'm not anymore sure about the data catched; shall I call my triggers
zzzzzzz in order to be sure to not break previous trigger set behavior?

Regards
Gaeatano Mendola