pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Peter Geoghegan <pg@bowt.ie>
To: Simon Riggs <simon@2ndquadrant.com>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Stephen Frost <sfrost@snowman.net>
Cc: Michael Paquier <michael.paquier@gmail.com>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: MERGE SQL Statement for PG11
Date: Fri, 3 Nov 2017 09:35:39 -0700
Message-ID: <20171103163539.GA17026@marmot> (raw)
In-Reply-To: <CANP8+j+JxXs8RWWpz2yRZdbWMti6M5rxyKZDY-yLvDt3ROOYMA@mail.gmail.com>
References: <CANP8+j+FPEqpd8O3scwOKUgRvtWB5r5RhcCuJ8nn6VU_wc2Nng@mail.gmail.com>
	<CAH2-Wz=AxEKE7sJEukPN3Vgu6sU5QwuLCBHuF-oJbkOLWsxTQw@mail.gmail.com>
	<CANP8+j+FM8ep1Cprbjaeknzq1pRAaxTMvX=hYsc4eGcj13fz7w@mail.gmail.com>
	<CA+TgmoYbytQT1pZDOK6t-XD=jWffDXaHoubsU-_mqJU6W0oK0w@mail.gmail.com>
	<20171030185511.GJ4628@tamriel.snowman.net>
	<CANP8+jJopkeYT_h_u=jb6euKVnXqRc77CiOk+hSwxOC-xtP0kQ@mail.gmail.com>
	<CA+TgmoYKesHek379ny4HtAi-nGszj_2VrQ4uvU60qV3BNSkGFQ@mail.gmail.com>
	<CANP8+j+iAAvW1VqTBkW7qbq+vB8GD+xYmgQoL5tvrhO0dBcXww@mail.gmail.com>
	<CA+TgmoYOyX4nyu9mbMdYTLzT9X-1RptxaTKSQfbSdpVGXgeAJQ@mail.gmail.com>
	<CANP8+j+JxXs8RWWpz2yRZdbWMti6M5rxyKZDY-yLvDt3ROOYMA@mail.gmail.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>

Simon Riggs <simon@2ndquadrant.com> wrote:
>>> The *only* behavioural difference I have proposed would be the *lack*
>>> of an ERROR in (some) concurrent cases.
>>
>> I think that's a big difference.  Error vs. non-error is a big deal by
>> itself;
>
>Are you saying avoiding an ERROR is a bad or good thing?

Are you really asking Robert to repeat what has already been said about
a dozen different ways?

That's *not* the only difference. You need to see a couple of steps
ahead to see further differences, as the real dilemma comes when you
have to reconcile having provided the UPSERT-guarantees with cases that
that doesn't map on to (which can happen in a number of different ways).

I don't understand why you'll talk about just about anything but that.
This is a high-level concern about the overarching design. Do you really
not understand the concern at this point?

>> also, the non-error case involves departing from MVCC
>> semantics just as INSERT .. ON CONFLICT UPDATE does.
>
>Meaning what exactly? What situation occurs that a user would be concerned with?
>
>Please describe exactly what you mean so we get it clear.
>
>The concurrent behaviour for MERGE is allowed to be
>implementation-specific, so we can define it any way we want.

Agreed -- we can. It isn't controversial at all to say that the SQL
standard has nothing to say on this question. The problem is that the
semantics you argue for are ill-defined, and seem to create more
problems than they solve. Why keep bringing up the SQL standard?

-- 
Peter Geoghegan


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers



view thread (265+ messages)  latest in thread

Message-ID: <20171103163539.GA17026@marmot>
Permalink:  ../20171103163539.GA17026@marmot/
Also on:    postgresql.org/message-id/20171103163539.GA17026@marmot

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: pg@bowt.ie, simon@2ndquadrant.com, robertmhaas@gmail.com, sfrost@snowman.net, michael.paquier@gmail.com
  Subject: Re: MERGE SQL Statement for PG11
  In-Reply-To: <20171103163539.GA17026@marmot>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox