Date: Mon, 30 Oct 2017 14:55:11 -0400
From: Stephen Frost <sfrost@snowman.net>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Simon Riggs <simon@2ndquadrant.com>, Peter Geoghegan <pg@bowt.ie>,
	Michael Paquier <michael.paquier@gmail.com>,
	PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: MERGE SQL Statement for PG11
Message-ID: <20171030185511.GJ4628@tamriel.snowman.net>
References: 
 <CANP8+jKitBSrB7oTgT9CY2i1ObfOt36z0XMraQc+Xrz8QB0nXA@mail.gmail.com>
 <CA+TgmoZuce2iHSBVpkX5qud-UbxhtY85opA47LTP=QW16J47wg@mail.gmail.com>
 <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>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="6GhlQVkdqWyn5nVY"
Content-Disposition: inline
In-Reply-To: 
 <CA+TgmoYbytQT1pZDOK6t-XD=jWffDXaHoubsU-_mqJU6W0oK0w@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org


--6GhlQVkdqWyn5nVY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

* Robert Haas (robertmhaas@gmail.com) wrote:
> On Sun, Oct 29, 2017 at 1:19 AM, Simon Riggs <simon@2ndquadrant.com> wrot=
e:
> > Nothing I am proposing blocks later work.
>=20
> That's not really true.  Nobody's going to be happy if MERGE has one
> behavior in one set of cases and an astonishingly different behavior
> in another set of cases.  If you adopt a behavior for certain cases
> that can't be extended to other cases, then you're blocking a
> general-purpose MERGE.
>=20
> And, indeed, it seems that you're proposing an implementation that
> adds no new functionality, just syntax compatibility.  Do we really
> want or need two syntaxes  for the same thing in core?  I kinda think
> Peter might have the right idea here.  Under his proposal, we'd be
> getting something that is, in a way, new.

+1.

I don't think MERGE should be radically different from other database
systems and just syntax sugar over a capability we have.  The
downthread comparison to partitioning isn't accurate either.

There's a reason that we have INSERT .. ON CONFLICT and not MERGE and
it's because they aren't the same thing, as Peter's already explained,
both now and when he and I had exactly this same discussion years ago
when he was working on implementing INSERT .. ON CONFLICT.  Time changes
many things, but I don't think anything's changed in this from the prior
discussions about it.

Thanks!

Stephen

--6GhlQVkdqWyn5nVY
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCgAGBQJZ93WPAAoJEO1sijiDR2RVNyEP/3PNXgeyTFlzA4X/55bOzrwr
EUDW6OVN/4+4kK9EZ0YdG/4iVVF8sS/uiOPtLfywXOYBVt5Us6LgrO0qq0yUVh0q
2r7cS8J8EBHc73AArAEjyqahiUtZ7xdntXGikMrKRxrAqrAmtM0/n6f6qH8j1qzu
zcmss0+QYvScjpa3aV2rNcjkNgeRHWH6xvFLxrdgh6kwJbCCxxc2p/5JFwwwk27y
7gX/khzQWkOp3vVQfcjD8ywiN9B/Ea23dqNvrA/jnEMTTe2gmjljmHI71ais6Fbk
j2TfBt8RIpt31qaLeIKVeelTXrFHrjEDzhbFf4/XkpTuWYkowDaEbCg60vv5BG+U
5+5zLaBXXBkv+guMkgMlEN2/GC5t7A+IYrO/j4YkLwuqdUWg3l50rVbhllp7qVie
/Gbstr5My2kSfA379uREkKLoE+C2WpLpdyvMBZmS9OaLWFiwPww2kKvrs3wMoWWN
Tr3B+ukpplvniH1qE+jGoPi+dze41SPocz8Ekxtmgv6Murpqla0PzwGur7/dbRdU
kSAERYPrafzScsS9QsYPLQtO1FVQQViNPX4Y87NqaUzgx2qvN6jtEpRGuC5RSjNc
ZyS5mNJhRnybkGEfTgz4vALRno4+dPQXbRyxlvBajmnjpNTKQXZLTh7eL2aWCNAQ
0RXrjPVbH42M+khs+7Ys
=2cSz
-----END PGP SIGNATURE-----

--6GhlQVkdqWyn5nVY--