Re: [HACKERS] MERGE SQL Statement for PG11
От | Stephen Frost |
---|---|
Тема | Re: [HACKERS] MERGE SQL Statement for PG11 |
Дата | |
Msg-id | 20171030185511.GJ4628@tamriel.snowman.net обсуждение исходный текст |
Ответ на | Re: [HACKERS] MERGE SQL Statement for PG11 (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: [HACKERS] MERGE SQL Statement for PG11
|
Список | pgsql-hackers |
* Robert Haas (robertmhaas@gmail.com) wrote: > On Sun, Oct 29, 2017 at 1:19 AM, Simon Riggs <simon@2ndquadrant.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
В списке pgsql-hackers по дате отправления: