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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] Effect of dropping a partitioned table's column over time
Дата
Msg-id 3672.1502072449@sss.pgh.pa.us
обсуждение исходный текст
Ответ на [HACKERS] Effect of dropping a partitioned table's column over time  (Thomas Munro <thomas.munro@enterprisedb.com>)
Ответы Re: [HACKERS] Effect of dropping a partitioned table's column over time  (Thomas Munro <thomas.munro@enterprisedb.com>)
Список pgsql-hackers
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.

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 :-(
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Amit Langote
Дата:
Сообщение: Re: [HACKERS] A bug in mapping attributes in ATExecAttachPartition()
Следующее
От: Amit Langote
Дата:
Сообщение: Re: [HACKERS] Effect of dropping a partitioned table's column overtime