Re: Broken defenses against dropping a partitioning column

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Mon, Jul 8, 2019 at 11:02 AM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> On Mon, Jul 8, 2019 at 10:32 AM Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> wrote:
>>> That said, I'm not sure I see the use case for an ALTER TABLE .. DROP
>>> COLUMN command that turns a partitioned table (with existing partitions
>>> containing data) into one non-partitioned table with all data minus the
>>> partitioning column(s).

>> I think it would be useful to have "ALTER TABLE blah NOT PARTITIONED" but I

> ...hit send too soon, and also, I don't think anyone will be very
> happy if they get that behavior as a side effect of a DROP statement,
> mostly because it could take an extremely long time to execute.

FWIW, I was imagining the action as being (1) detach all the child
partitions, (2) make parent into a non-partitioned table, (3)
drop the target column in each of these now-independent tables.
No data movement. Other than the need to acquire locks on all
the tables, it shouldn't be particularly slow.

But I'm still not volunteering to write it, because I'm not sure
anyone would want such a behavior.

regards, tom lane