On Tue, Jul 29, 2014 at 1:28 PM, Peter Geoghegan <pg@heroku.com> wrote:
> 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.
You've convinced me that only indexable predicates can be sensibly
used here. I'm not sure that's the same as saying that upserts are
driven by inserts, though. I'd tend to interpret that to mean
insert-the-heap-tuple-first, but I think what you're doing is
check-the-indexes-first. The terminology in this area is tricky.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
