Re: support for MERGE
Alvaro Herrera <alvherre@alvh.no-ip.org>
From: Álvaro Herrera <alvherre@alvh.no-ip.org>
To: Amit Langote <amitlangote09@gmail.com>
Cc: Daniel Westermann <dwe@dbi-services.com>, pgsql-hackers@lists.postgresql.org, Simon Riggs <simon.riggs@enterprisedb.com>, Pavan Deolasee <pavan.deolasee@gmail.com>
Date: 2021-11-16T16:25:37Z
Lists: pgsql-hackers
Hi Amit On 2021-Nov-16, Amit Langote wrote: > AFAICS, MERGE operating on an inheritance parent that is not > partitioned should work mostly the same as the case where it is > partitioned (good thing that it works at all without needing any > special code!), though only the INSERT actions would have to be > handled appropriately by the user using triggers and such. And also I > guess any UPDATE actions that need to move rows between child tables > because that too involves tuple routing logic. As long as we're clear > on that in the documentation, I don't see why this case should not be > covered in the initial version. Yeah, I think the reason it works so cleanly is that the code you and/or Tom added to be able to get rid of inheritance_planner is superb, including the new row identity stuff. For the same reason, I suspect that adding support for foreign tables should be reasonably simple -- just add explicit support for handling "wholerow" in a few places. I have not tried. > I thought for a second about the cases where child tables have columns > not present in the root parent mentioned in the command, but I guess > that possibility doesn't present problems given that the command > wouldn't be able to mention such columns to begin with; it can only > refer to the root parent's column which must be present in all of the > affected child tables. Right. On the other hand, if we did have a problem with extra columns, ISTM that would be on the user's head, not our responsibility. In the example I added, there is one child table with variant column layout; it did require that the insertion trigger explicitly lists the columns in the INSERT statement for that table, but otherwise it work correctly. > In any case, I have a feeling that the planner would catch any > problematic cases if there're any while converting MergeAction > expressions into the individual child table layouts. Yeah, AFAICS it worked fine for the case I tried. Maybe there are more elaborate ones that I didn't think of, of course. -- Álvaro Herrera 39°49'30"S 73°17'W — https://www.EnterpriseDB.com/ "Puedes vivir sólo una vez, pero si lo haces bien, una vez es suficiente"
Commits
-
Doc fixes for MERGE statement
- 5dcebd10baa8 16.0 landed
- 5bb88967ed5c 15.0 landed
-
MERGE docs adjustments
- d6d1fbf353d1 15.0 landed
- 3d895bc846f2 16.0 landed
-
Link to MVCC docs in MERGE docs
- ffffeebf2447 15.0 landed
-
Fix EXPLAIN MERGE output when no tuples are processed
- 12e423e21d8e 15.0 landed
-
Make EXPLAIN MERGE output format more compact
- 598ac10be1c2 15.0 landed
-
Add support for MERGE SQL command
- 7103ebb7aae8 15.0 landed
-
Split ExecUpdate and ExecDelete into reusable pieces
- 25e777cf8e54 15.0 landed
-
Add API of sorts for transition table handling in trigger.c
- 3a46a45f6f00 15.0 landed
-
Represent Lists as expansible arrays, not chains of cons-cells.
- 1cff1b95ab6d 13.0 cited