Date: Tue, 31 Oct 2017 07:56:19 -0400
From: Stephen Frost <sfrost@snowman.net>
To: Simon Riggs <simon@2ndquadrant.com>
Cc: Robert Haas <robertmhaas@gmail.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: <20171031115618.GQ4628@tamriel.snowman.net>
References: 
 <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>
 <20171030185511.GJ4628@tamriel.snowman.net>
 <CANP8+jJopkeYT_h_u=jb6euKVnXqRc77CiOk+hSwxOC-xtP0kQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="FkkqDIBV64S0HxLI"
Content-Disposition: inline
In-Reply-To: 
 <CANP8+jJopkeYT_h_u=jb6euKVnXqRc77CiOk+hSwxOC-xtP0kQ@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org


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

Simon,

* Simon Riggs (simon@2ndquadrant.com) wrote:
> On 30 October 2017 at 19:55, Stephen Frost <sfrost@snowman.net> wrote:
> > I don't think MERGE should be radically different from other database
> > systems and just syntax sugar over a capability we have.
>=20
> I've proposed a SQL Standard compliant implementation that would do
> much more than be new syntax over what we already have.
>=20
> So these two claims aren't accurate: "radical difference" and "syntax
> sugar over a capability we have".

Based on the discussion so far, those are the conclusions I've come to.
Saying they're isn't accurate without providing anything further isn't
likely to be helpful.

> > Time changes
> > many things, but I don't think anything's changed in this from the prior
> > discussions about it.
>=20
> My proposal is new, that is what has changed.

I'm happy to admit that I've missed something in the discussion, but
=66rom what I read the difference appeared to be primairly that you're
proposing it, and doing so a couple years later.

> At this stage, general opinions can be misleading.

I'd certainly love to see a MERGE capability that meets the standard and
works in much the same way from a user's perspective as the other RDBMS'
which already implement it.  From prior discussions with Peter on
exactly that subject, I'm also convinced that having that would be a
largely independent piece of work from the INSERT .. ON CONFLICT
capability that we have (just as MERGE is distinct from similar UPSERT
capabilities in other RDBMSs).

The goal here is really just to avoid time wasted developing MERGE based
on top of the INSERT .. ON CONFLICT system only to have it be rejected
later because multiple other committers and major contributors have said
that they don't agree with that approach.  If, given all of this
discussion, you don't feel that's a high risk with your approach then by
all means continue on with what you're thinking and we can review the
patch once it's posted.

Thanks!

Stephen

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

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

iQIcBAEBCgAGBQJZ+GTiAAoJEO1sijiDR2RVSD0QAIfRdVp8EZhiyYgaA5GJeiqV
WGGImqg0V89MWmzCJniZ2kKwAC263nL7anZ6CQSDN0pOTtvVFy0Vupi/tiCMBu4M
cTgYHSzE1e1KHvlT0B4YGjmb1+n2cloi1D4E5OBE0GVKNxdarSZ1i5WyQbEOXpDh
Q+vOwxIzJe6hNGd9HHMCOYtlowtZzJM3oES16b32TFC79M2T3BJwK5iJlPSyzF/e
QffGtlWW+2abBB9GVlPN+P2jVxgCxWPF3UKcIP4Q0zgjMVg/G2WsMr7SGk922X/N
N0CeZky0q9CioAOw14KnZSzglhZbobdEE+bTFxKWJ2mDIfAFDmRlV82WvG/FDcWz
uT3uGaOO6JU1/qZfWbTtAyMSKZTSMhvPYrcaWRpNffbamglMprB+rKrMBcTynMO9
hlj3aK5VjF1+nsypu2+RZcH0ZWbDqTCNOJtMAomCNLnoZloT2C3eTcZZ9M5jrc79
ClSLU4q9bfkWIfX4yUa4C3fUTy8UmKCrCs/3bzjB+52pg5rgc3vC0TlO1gE2vN+1
WpFaExJj2lJmS3LSToXGO9qPE4pHzSksd8LfmTLDtGnbjldynJDabPx3lJHGfMCS
mmB8B5QHvvfoweR6ZDnenOvqfjtTx0bZvVtRNGeyEwAI1DkrExOisffi96TM9+0v
30ocku4ak3dEaQdF6ata
=OTgV
-----END PGP SIGNATURE-----

--FkkqDIBV64S0HxLI--