On 7 August 2017 at 11:25, Thomas Munro <thomas.mu...@enterprisedb.com> wrote:
> On Mon, Aug 7, 2017 at 2:20 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > > Thomas Munro <thomas.mu...@enterprisedb.com> writes: > >> Since partitioned tables have no storage themselves, is there > >> any technical reason we couldn't remove a partitioned table's dropped > >> pg_attribute so that its TupleDesc matches partitions created later? > > > > You'd break views referring to the partitioned table, or at least to > > any columns after the dropped one. > > I will put a huge sign up next to my desk: "What about the rules?" > > > There's been talk of separating column identity (think OID) from column > > logical and physical positions. If we did that, and had Vars using the > > column identity number while tupdescs were sorted according to physical > > position, then what you're thinking of could be made to work. But a > > couple of people have attacked that problem and been unable to finish > > it :-( > > Hmm, yeah I see. I have seen that[1] and I hope it comes back. It > seems like it might be a step on the path towards incremental > materialized views (at least in one proposal) which is why I asked > about it on this list recently[2]. > Can we instead create the new partitions with the same dropped columns? Ensure that every partition, parent and child, has the same column-set? -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
