Unless I'm just off my rocker, I seem to remember that if you start updating a row, rows referenced
by foreign key values will also get locked on that same transaction (or at least attempt to do so --
some sort of read-lock?) In our case, this meant that if you're in the middle of updating
someone's SSN, and you try to also update their address (popup-screen of dependent record on a
different transaction) you'll get a deadlock (we use NOWAIT, so it's at least not too irritating.)

(when someone starts editing, we explicitely do 'update {tablename} set id = id where id =
{value}' -- this conflicts with parent records already being edited. as we've already selected the
data, we don't bother reselecting 'for update'.)

We've not really minded ... but I was wondering if someone could give me the theory behind this?
Why would you automatically lock rows referenced (such as master records) when updating others
(dependent records)? Is it necessary to reduce logical errors from multiple transactions competing
for resources that aren't the identical, but related?

In case it matters, methinks we're still running 1.0.2 ... and of course, again, I could just be
remembering incorrectly.

Thanks,
-Philip