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.
>
> I've proposed a SQL Standard compliant implementation that would do
> much more than be new syntax over what we already have.
>
> 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.
>
> My proposal is new, that is what has changed.
I'm happy to admit that I've missed something in the discussion, but
from 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