Re: Making joins involving ctid work for the benefit of UPSERT - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: Making joins involving ctid work for the benefit of UPSERT
Date
Msg-id CAM3SWZRtMJKH_043bbO+4X7N=NgwaAMLuiTv=pq32CPSDx7hYg@mail.gmail.com
Whole thread Raw
In response to Re: Making joins involving ctid work for the benefit of UPSERT  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Making joins involving ctid work for the benefit of UPSERT  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Tue, Jul 29, 2014 at 9:56 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> I think it would be advisable to separate the syntax from the
> implementation.  Presumably you can make your implementation use some
> reasonable syntax we can all agree on, and conversely my proposed
> syntax could be made to have a different set of semantics.  There's
> some connection between the syntax and semantics, of course, but it's
> not 100%.  I mention this because I was mostly concerned with getting
> to a reasonable syntax proposal, not so much the implementation
> details.  It may well be that your implementation details are perfect
> at this point; I don't know because I haven't looked, and I'm not an
> expert on that area of the code anyway.  But I have looked at your
> syntax, which I wasn't altogether keen on.


Fair enough. I think the syntax should reflect the fact that upserts
are driven by inserts, though. Users will get into trouble with a
syntax that allows a predicate that is evaluated before any rows are
locked.

-- 
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Making joins involving ctid work for the benefit of UPSERT
Next
From: Simon Riggs
Date:
Subject: Re: Performance issue in pg_dump's dependency loop searching