Florian Pflug <fgp(at)phlo(dot)org> wrote:
> Part (B) has some relationship to what I tried to archive by
> changing the way REPEATABLE READ transactions and row locks
> interact. Though my intention wasn't full serializability, only
> enough protection to make user-space FOREIGN KEYS work safely for
> REPEATABLE READ transactions.
Florian, I know that you looked at Oracle's treatment of SELECT FOR
UPDATE, so could you respond to Tom's question about the semantics
of that? (From what you and Patrick have posted I gather that from
a user visible logical perspective SELECT FOR UPDATE is the same as
a no-op UPDATE RETURNING, although there may be performance
differences. From Patrick's recent post I gather that MS SQL Server
[at least in some configuration -- it has many settings which might
affect this] behaves the same as Oracle in this regard; while DB2 is
more strict, using a predicate lock on the selected range. But my
take on that is second-hand, based on those posts and discussions
with Oracle users a PGEast -- it'd be better for a report from
someone who looked at it directly.)
-Kevin