Re: [HACKERS] MERGE SQL Statement for PG11
Peter Geoghegan <pg@bowt.ie>
From: Peter Geoghegan <pg@bowt.ie>
To: Simon Riggs <simon@2ndquadrant.com>
Cc: Pavan Deolasee <pavan.deolasee@gmail.com>,
Alvaro Herrera <alvherre@alvh.no-ip.org>, Robert Haas <robertmhaas@gmail.com>,
Tomas Vondra <tomas.vondra@2ndquadrant.com>, Andrew Dunstan <andrew.dunstan@2ndquadrant.com>, Pavan Deolasee <pavan.deolasee@2ndquadrant.com>,
Stephen Frost <sfrost@snowman.net>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2018-03-23T20:06:42Z
Lists: pgsql-hackers
Attachments
- 0001-support-CTEs-with-MERGE.patch (text/x-patch) patch 0001
On Fri, Mar 23, 2018 at 6:55 AM, Simon Riggs <simon@2ndquadrant.com> wrote: > Peter, if you have the code and you consider it important that this > subfeature is in PostgreSQL, why not post the code so we can commit > it? Fair enough. Attached patch shows what I'm on about. This should be applied on top of 0001_merge_v23e_onconflict_work.patch + 0002_merge_v23e_main.patch. I'm not expecting an authorship credit for posting this patch. One thing that the test output shows that is interesting is that there is never a "SubPlan 1" or "InitPlan 1" in EXPLAIN output -- it seems to always start at "SubPlan 2". This probably has nothing to do with CTEs in particular. I didn't notice this before now, although there were no existing tests of EXPLAIN in the patch that show subplans or initplans. Is this somehow related to the issue of using two RTEs for the target relation? That's certainly why we always see unaliased target table "m" with the alias "m_1" in EXPLAIN output, so I would not be surprised if it caused another EXPLAIN issue. -- Peter Geoghegan
Commits
-
Add support for MERGE SQL command
- 7103ebb7aae8 15.0 landed
-
Add API of sorts for transition table handling in trigger.c
- 3a46a45f6f00 15.0 landed
-
Revert MERGE patch
- 08ea7a2291db 11.0 cited
-
Fix several bugs related to ON CONFLICT's EXCLUDED pseudo relation.
- ad2278379244 9.6.0 cited