From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, Peter Geoghegan <pg(at)bowt(dot)ie>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: MERGE SQL Statement for PG11 |
Date: | 2017-10-30 18:55:11 |
Message-ID: | 20171030185511.GJ4628@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
* Robert Haas (robertmhaas(at)gmail(dot)com) wrote:
> On Sun, Oct 29, 2017 at 1:19 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> > Nothing I am proposing blocks later work.
>
> 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.
>
> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2017-10-30 19:04:22 | Re: Re: PANIC: invalid index offnum: 186 when processing BRIN indexes in VACUUM |
Previous Message | Nico Williams | 2017-10-30 18:36:50 | Re: MERGE SQL Statement for PG11 |