On 30 October 2017 at 19:55, Stephen Frost <sfrost@snowman.net> wrote:
> * 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.
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".
> 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.
At this stage, general opinions can be misleading.
Hi ho, hi ho.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers