Re: Another way to fix inherited UPDATE/DELETE
От | David Rowley |
---|---|
Тема | Re: Another way to fix inherited UPDATE/DELETE |
Дата | |
Msg-id | CAKJS1f_5k3PcY=GF5a=eH1=mcptrnVESR-CEpx6hTDweyGUu6w@mail.gmail.com обсуждение исходный текст |
Ответ на | Another way to fix inherited UPDATE/DELETE (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Another way to fix inherited UPDATE/DELETE
|
Список | pgsql-hackers |
On Wed, 20 Feb 2019 at 10:49, Tom Lane <tgl@sss.pgh.pa.us> wrote: > What if we dropped that idea, and instead defined the plan tree as > returning only the columns that are updated by SET, plus the row > identity? It would then be the ModifyTable node's job to fetch the > original tuple using the row identity (which it must do anyway) and > form the new tuple by combining the updated columns from the plan > output with the non-updated columns from the original tuple. > > DELETE would be even simpler, since it only needs the row identity > and nothing else. While I didn't look at the patch in great detail, I think this is how Pavan must have made MERGE work for partitioned targets. I recall seeing the tableoid being added to the target list and a lookup of the ResultRelInfo by tableoid. Maybe Pavan can provide more useful details than I can. -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: