Tom Lane wrote:
>
> "Froggy / Froggy Corp." <froggy@froggycorp.com> writes:
> > PG7 dont make recursiv, it wait for the end of the trigger BEFORE_UPDATE
> > to call the new UPDATE stat and forgot the 3rd AFTER_UPDATE. PG8 is
> > better, it call trigger like real recursiv fonction, but allways dismiss
> > the 3rd AFTER UPDATE.
>
> There isn't any third AFTER UPDATE because the updates fired by the
> trigger override the pending update, and so when the trigger returns
> the pending update is abandoned.
>
> 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.
Because the trigger call itself, this way is more easy and decrease
considerably all possibility.
In fact, i thought that for "recursiv" trigger, PG alocate a new trigger
in memory, so it should not be a problem.
I dont know if its really bad, but i dont see any more option to do it
(btw, i will need to change these part to make trigger working). All
trigger for this table work like that.
Regards,