| From: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
|---|---|
| To: | Nico Williams <nico(at)cryptonector(dot)com> |
| Cc: | Peter Geoghegan <pg(at)bowt(dot)ie>, Robert Haas <robertmhaas(at)gmail(dot)com>, 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-11-03 07:44:16 |
| Message-ID: | CANP8+j+w_aqC3_NpjFzh6D3jmitjPVPTiD7strM3QLNh=UFTdg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2 November 2017 at 22:59, Nico Williams <nico(at)cryptonector(dot)com> wrote:
> On Thu, Nov 02, 2017 at 03:25:48PM -0700, Peter Geoghegan wrote:
>> Nico Williams <nico(at)cryptonector(dot)com> wrote:
>> >A MERGE mapped to a DML like this:
>>
>> This is a bad idea. An implementation like this is not at all
>> maintainable.
>
> Assuming the DELETE issue can be addressed, why would this not be
> maintainable?
It would only take one change to make this approach infeasible and
when that happened we would need to revert to the full-executor
version.
One difference that comes to mind is that MERGE doesn't behave the
same way as an UPDATE-join, according to SQL:2011 in that it must
throw an error if duplicate changes are requested. That would be hard
to emulate using a parser only version.
I would call it impressively clever but likely fragile, in this case,
though I encourage more ideas like that in the future.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Thomas Kellerer | 2017-11-03 07:46:20 | Re: MERGE SQL Statement for PG11 |
| Previous Message | Simon Riggs | 2017-11-03 07:35:07 | Re: MERGE SQL Statement for PG11 |