Simon Riggs wrote: > On 31 October 2012 19:35, Noah Misch <n...@leadboat.com> wrote: > > On Mon, Oct 29, 2012 at 08:18:33AM -0400, Kevin Grittner wrote: > >> Andres Freund wrote:
> >> > 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. > > > > +1. I had not considered this angle during previous reviews, but I agree > > with > > Andres's position. Since this patch does not strengthen the strongest tuple > > lock relative to its PostgreSQL 9.2 counterpart, that lock type should > > continue to use the syntax "FOR UPDATE". It will come to mean "the lock > > type > > sufficient for all possible UPDATEs of the row". Yeah, I agree with this too. > So we have syntax > > FOR NON KEY UPDATE > FOR KEY UPDATE > > KEY is the default, so FOR UPDATE is a synonym of FOR KEY UPDATE Not really sure about the proposed syntax, but yes clearly we need some other syntax to mean "FOR NON KEY UPDATE". I would rather keep FOR UPDATE to mean what I currently call FOR KEY UPDATE. More proposals for the other (weaker) lock level welcome (but if you love FOR NON KEY UPDATE, please chime in too) -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
