| From: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Pavan Deolasee <pavan(dot)deolasee(at)2ndquadrant(dot)com> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Another way to fix inherited UPDATE/DELETE |
| Date: | 2019-02-19 22:53:19 |
| Message-ID: | CAKJS1f_5k3PcY=GF5a=eH1=mcptrnVESR-CEpx6hTDweyGUu6w@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, 20 Feb 2019 at 10:49, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Thomas Munro | 2019-02-19 22:57:26 | Re: Some thoughts on NFS |
| Previous Message | Andres Freund | 2019-02-19 22:44:45 | Re: Another way to fix inherited UPDATE/DELETE |