Its my plan in fact, it was to make some optimisation, because i need to copy all the test from the BEFORE statement to the AFTER. Thx for your help, Regards, Tom Lane wrote: > > "Froggy / Froggy Corp." <froggy@xxxxxxxxxxxxxx> writes: > > Tom Lane wrote: > >> This is a really badly designed trigger anyway: why don't you just > >> modify the NEW row, instead of incurring orders of magnitude more work > >> by launching an entire new SQL command? > > > I make some reorganization of my table when user make an update. The > > trigger need to be able to support lot of case, so to make > > reorganization more simple, i make some test, and change or make change > > of this table by other part of trigger which are on after_update or > > before_update. > > If you are cascading changes to other rows, you should do them in AFTER > triggers. It's not really very sensible to try to do that in a BEFORE > trigger, because a BEFORE trigger shouldn't assume it's seeing the final > version of the row. BEFORE triggers are good for checking or adjusting > the data in the proposed new row, but for pushing consequences out to > other rows, use an AFTER trigger. > > regards, tom lane
