On Mon, 5 May 2003, Tom Lane wrote:
> Stephan Szabo <sszabo@megazone23.bigpanda.com> writes:
> > Actually, I think from sql99's description, for after row triggers it
> > should happen after the row is modified not after the statement as a
> > whole (so given two 2 row updates in a function you'd get
> > update1,row1 afterrow1-1 update1,row2 afterrow1-2,afterstatement1
> > update2,row1 afterrow2-1 update2,row2 afterrow2-2,afterstatement2
> > )
>
> [ scratches head ... ] That seems a useless definition. What is the
> purpose of firing immediately after, rather than immediately before,
> a row update? Wouldn't you want to wait till end of statement so you
> know that the whole statement is in fact going to complete (and not
> die at some later row)? What do you have immediately after the update
> that you didn't have just before it?
You're right, I'd misread "the trigger event" as being a row change for a
row trigger (go figure). However, looking at it, then I'm not sure our
before row trigger timing is correct then. It seems from 14.14 for a
delete example that the timing is supposed to be something like:
before trigger 1before trigger 2delete 1delete 2after trigger 1after trigger 2
rather than:before trigger 1delete 1before trigger 2delete 2after trigger 1after trigger 2