From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Noah Misch <noah(at)leadboat(dot)com>, Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: map_partition_varattnos() and whole-row vars |
Date: | 2017-07-28 19:26:25 |
Message-ID: | 28692.1501269985@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> If we're remapping the varattnos, I don't see how we can just pass
> whole-row references through. I mean, if the partition and the parent
> have different varattnos, then a whole-row attribute for one is a
> different thing from a whole-row attribute for the other; the
> HeapTuple you would need to build in each case is different, based on
> the column order for the relation you're worrying about.
There is longstanding code in the planner to handle this for traditional-
inheritance cases; IIRC what it does is build a ROW() expression that
emits the proper output rowtype regardless of the discrepancies.
Not sure why that's apparently not getting applied for partitioning.
> (Boy, our implementation of DROP COLUMN is painful! If we really got
> rid of columns when they were dropped we could've avoided this whole
> mess.)
I think the pain arises mostly from the decision to allow partitions
to not all have identical rowtype. I would have lobbied against that
choice if I'd been paying more attention at the start ... but I wasn't.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Scott Milliken | 2017-07-28 19:35:27 | Re: BUG #14758: Segfault with logical replication on a function index |
Previous Message | Peter Geoghegan | 2017-07-28 19:08:00 | Re: map_partition_varattnos() and whole-row vars |