"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