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@froggycorp.com> 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

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq