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  (Pavan Deolasee <pavan.deolasee@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Another way to fix inherited UPDATE/DELETE
Следующее
От: Thomas Munro
Дата:
Сообщение: Re: Some thoughts on NFS