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

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