Re: [HACKERS] MERGE SQL Statement for PG11

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>, Pavan Deolasee <pavan(dot)deolasee(at)2ndquadrant(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] MERGE SQL Statement for PG11
Date: 2018-01-29 17:23:58
Message-ID: CAH2-WzmHBJymyv1KXV6d5Fun4qMuoo1xuGXa6tbkSYRcaapM9w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jan 29, 2018 at 8:44 AM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> On Mon, Jan 29, 2018 at 04:34:48PM +0000, Simon Riggs wrote:
>> The only discussion would be about the word "unfinished". I'm not
>> clear why this patch, which has current caveats all clearly indicated
>> in the docs, differs substantially from other projects that have
>> committed their work ahead of having everything everybody wants, such
>> as replication, materialized views, parallel query, partitioning,
>> logical decoding etc.. All of those features had caveats in the first
>> release in which they were included and many of them were committed
>> prior to the last CF. We are working now to remove those caveats. Why
>> is this different? It shouldn't be. If unfinished means it has caveats
>> that is different to unfinished meaning crappy, risky, contentious
>> etc..
>
> I think the question is how does it handle cases it doesn't support?
> Does it give wrong answers? Does it give a helpful error message? Can
> you summarize that?

+1

ON CONFLICT had support for logical decoding, updatable views, and RLS
in the first commit. ON CONFLICT was committed in a form that worked
seamlessly with any other feature in the system you can name. Making
ON CONFLICT play nice with all adjacent features was a great deal of
work, and I definitely needed Andres' help for the logical decoding
part, but we got it done. (Logical decoding for MERGE should be quite
a lot easier, though.)

I'm willing to talk about why MERGE is different to ON CONFLICT, and
why it may not need to tick all of the same boxes. DML statements are
supposed to be highly composable things, though. That's the premise
you should start from IMV.

--
Peter Geoghegan

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2018-01-29 17:35:15 Re: [HACKERS] MERGE SQL Statement for PG11
Previous Message Pavel Stehule 2018-01-29 17:18:08 Re: [HACKERS] MERGE SQL Statement for PG11