Tom Lane wrote: > > "Froggy / Froggy Corp." <froggy@xxxxxxxxxxxxxx> 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,
