Re: Recursion in triggers?

Ya, I worded the original poorley. Let me try again....

The after update trigger on the table sets some of the NEW.column values for record A. Then it executes another update on the same table, but on record B. That second execution of the update trigger needs to see the mods made to record A.

One table being updated, calling more updates in the after trigger, needs to see the mods made in the previous update trigger executions.

It's like a cascading operation, but on just one table.

Sorry about the confussion, and thanks for the help.

-----Original Message-----
From: Craig Ringer [mailto:craig(at)postnewspapers(dot)com(dot)au]
Sent: Sunday, January 24, 2010 11:34 AM
To: Gauthier, Dave
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: [GENERAL] Recursion in triggers?

Gauthier, Dave wrote:

> What I need to know is if, in the "after" update trigger I make the
> subsequent updates to other records in the same table, with the OLD/NEW
> record ponters be set properly in those subsequent update trigger
> invocations?

They'll be set properly. I'm not sure they'll be set how you
want/expect, though.

> Will the current and modified NEW.* values be passed down
> into the next update trigger "before" call as OLD.* values?

Eh? Why would they? Your AFTER trigger when fired modifies a different
record, right, rather than modifying the same one again. So why would
the `NEW' and `OLD' variables in the second firing have anything to do
with those in the first firing?

(Or have I misunderstood what you're trying to ask?)

Is your question really one about when the changes become visible? Ie,
if an AFTER UPDATE ... FOR EACH ROW trigger performs an UPDATE on a
table, does the second instance of that same trigger procedure see the
changes made to the first row?

That I can't give you a guaranteed-accurate answer to right now (though
"I think so") ... but suggest that writing a simple test case would be a
a pretty conclusive way to find out if the docs are unclear.

--
Craig Ringer