Florian Pflug <f...@phlo.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
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
