Andres Freund wrote: > On Sunday, October 28, 2012 11:47:16 PM Simon Riggs wrote: >> Andres Freund <and...@2ndquadrant.com> wrote:
>>> * Is it ok to make FOR UPDATE somewhat weaker than before? In 9.2 >>> and earlier you could be sure that if you FOR UPDATE'ed a row you >>> could delete it. Unless I miss something now this will not block >>> somebody else acquiring a FOR KEY SHARE lock, so this guarantee >>> is gone. >> >> Yes, that is exactly the point of this. > > The point is the introduction of a weaker lock level which can be > used by the ri triggers. I don't see any imperative that the > semantics of the old lock level need to be redefined. That just > seems dangerous to me. I agree with Andres here -- the new lock level is needed within RI triggers, and we might as well expose it for application programmer use (with proper documentations), but there's no reason to break existing application code by making the semantics of SELECT FOR UPDATE less strict than they were before. Let's keep that term meaning exactly the same thing if we can, and use new names for the new levels. We already present a barrier to people migrating from Oracle because SELECT FOR UPDATE in PostgreSQL is weaker than it is in Oracle (where it is just as strong as if an actual UPDATE were done -- write conflicts and all); let's not increase the barrier by making SELECT FOR UPDATE even weaker. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
