> 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?
It seems like the select-and-check method, even though it may be redundant
most of the time, is the belt-and-suspenders way of avoiding an infinite loop.
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?
--
Mike Nolan
