Re: Broken defenses against dropping a partitioning column
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>,
PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
Manuel Rigger <rigger.manuel@gmail.com>
Date: 2019-07-08T15:07:59Z
Lists: pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes: > On Mon, Jul 8, 2019 at 11:02 AM Robert Haas <robertmhaas@gmail.com> wrote: >> On Mon, Jul 8, 2019 at 10:32 AM Alvaro Herrera <alvherre@2ndquadrant.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
Commits
-
Make pg_upgrade's test.sh less chatty.
- 8d21512dc34f 11.5 landed
- 7ac7bf50cc9a 10.10 landed
- 75348a733225 9.6.15 landed
- 69c3d519112f 9.5.19 landed
- 19f9a5aed9a7 9.4.24 landed
-
Install dependencies to prevent dropping partition key columns.
- a0555ddab9b6 13.0 landed
- 79e573fa4986 12.0 landed
- 6cdefc82ba9d 11.5 landed
- 0e1deaa4c424 10.10 landed