Re: Trigger loop question

Mike Nolan <nolan(at)gw(dot)tssi(dot)com> 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