Re: Effect of dropping a partitioned table's column over time

On 7 August 2017 at 11:25, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>
wrote:

> On Mon, Aug 7, 2017 at 2:20 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)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