> Ok, in multi-version systems readers never lock
> selected rows and so never block writers. Nice but
> cause problems in some cases: if you want
> to implement referential integrity at the
> application level then you'll have to use
> LOCK TABLE IN SHARE MODE or SELECT FOR UPDATE to
> prevent updation of primary keys etc. Not so good...
I was wondering if there is another perspective
to look upon this problem.
Assertion:
The primary difference between "primary key" and
"unique key" is that primary keys are _never_
updated (during transaction processing) where
unique keys may be.
Question:
It seems that the techinical solution here may
not be better locking, but rather a mechinism
to prevent updates on primary keys unless the
entire table is locked, or some other dramatic
gesture for non-transaction processing.
This leaves the issue of delete looming, so
mabye the suggestion won't help.
Clark
