Mike Nolan <[EMAIL PROTECTED]> writes:
>> Actually, I wasn't thinking very clearly. The easiest way to break
>> the loop is to avoid updating the other table when OLD.x = NEW.x
>> in the trigger's arguments. The other way requires a rather-redundant
>> SELECT to see what is in the other table.
> If I have to update the other table for any other purpose as part of
> that trigger, or if some other trigger updates that table, couldn't that
> result in an infinite loop?
Well, I'm assuming that your update logic converges to a fixed state;
if it doesn't, seems like you've got problems anyway ...
> Here's a really weird question. If in the trigger for table A I have
> more than one statement that updates table B, or if more than one trigger
> procedure updates table B, does that cause multiple firings of either
> before or after update triggers on table B?
Yes, and yes. You get one firing per row update event, IIRC, no matter
where that update came from.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
