Date: Thu, 2 Nov 2017 11:14:01 -0700
From: Peter Geoghegan <pg@bowt.ie>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Simon Riggs <simon@2ndquadrant.com>, Stephen Frost <sfrost@snowman.net>,
	Michael Paquier <michael.paquier@gmail.com>,
	PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: MERGE SQL Statement for PG11
Message-ID: <20171102181401.GB23098@marmot>
References: 
 <CANP8+j+jG76Okkibk7Xu=T6C5-gSpXX9sudANS9nGyR9yWEgRA@mail.gmail.com>
 <CA+TgmobMx66NWCoje=PEGnbMQQdZojJi7v9RqsuY23vkNsTf1Q@mail.gmail.com>
 <CAB7nPqRzN4bE7EfVFgt64LA8FLMCV9=VGr8=FeogVEOiUbj4Ww@mail.gmail.com>
 <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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
In-Reply-To: 
 <CA+TgmoYKesHek379ny4HtAi-nGszj_2VrQ4uvU60qV3BNSkGFQ@mail.gmail.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

Robert Haas <robertmhaas@gmail.com> wrote:
>And if, in the meantime, MERGE can only handle the cases where there
>is a unique index, then it can only handle the cases INSERT .. ON
>CONFLICT UPDATE can cover, which makes it, as far as I can see,
>syntactic sugar over what we already have.  Maybe it's not entirely -
>you might be planning to make some minor functional enhancements - but
>it's not clear what those are, and I feel like whatever it is could be
>done with less work and more elegance by just extending the INSERT ..
>ON CONFLICT UPDATE syntax.

+1

Marko Tiikkaja's INSERT ... ON CONFLICT SELECT patch, which is in the
current CF [1], moves things in this direction. I myself have
occasionally wondered if it was worth adding an alternative DO DELETE
conflict_action. This could appear alongside DO UPDATE, and be applied
using MERGE-style conditions.

All of these things seem like small adjuncts to ON CONFLICT because
they're all just an alternative way of modifying or projecting the tuple
that is locked by ON CONFLICT. Everything new would have to happen after
the novel ON CONFLICT handling has already completed.

The only reason that I haven't pursued this is because it doesn't seem
that compelling. I mention it now because It's worth acknowledging that
ON CONFLICT could be pushed a bit further in this direction. Of course,
this still falls far short of making ON CONFLICT entirely like MERGE.

[1] https://commitfest.postgresql.org/15/1241/
-- 
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