FOR SHARE LOCK clause ?

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...

So, what about FOR SHARE LOCK clause in SELECTs?
Like FOR UPDATE clause, FOR SHARE LOCK clause
will lock selected rows, but in _share_ mode.
This is some kind of read-locking on demand.

Disadvantages:

1. FOR SHARE LOCK will use lock manager to
lock rows, but lmgr can't handle "too many" locks.
(note that UPDATE, DELETE & SELECT FOR UPDATE use only
one entry in lmgr table for ALL updated/marked_for_update
rows).

2. UPDATE/DELETE will go slower than now: server will have to
exclusively lock (using lmgr) each row being updated, update/delete
it and release lmgr' lock after that (note that currently
lmgr locking is not used for rows). On the other hand,
SELECT FOR SHARE LOCK could mark locked rows in buffer
(t_infomask |= HEAP_MARKED_FOR_SHARE) and so UPDATE/DELETE
could acquire lmgr lock only if row is marked...

Comments ?

Vadim