Re: Broken defenses against dropping a partitioning column

Tomas Vondra <tomas.vondra@2ndquadrant.com> writes:
> On Mon, Jul 08, 2019 at 10:58:56AM -0400, Tom Lane wrote:
>> So I think we're probably stuck with the approach of adding new internal
>> dependencies.  If we go that route, then our options for the released
>> branches are (1) do nothing, or (2) back-patch the code that adds such
>> dependencies, but without a catversion bump.  That would mean that only
>> tables created after the next minor releases would have protection against
>> this problem.  That's not ideal but maybe it's okay, considering that we
>> haven't seen actual field reports of trouble of this kind.

> Couldn't we also write a function that adds those dependencies for
> existing objects, and request users to run it after the update?

Maybe.  I'm not volunteering to write such a thing.

BTW, it looks like somebody actually did think about this problem with
respect to external dependencies of partition expressions:

regression=# create function myabs(int) returns int language internal as 'int4abs' immutable strict parallel safe;
CREATE FUNCTION
regression=# create table foo (f1 int) partition by range (myabs(f1));
CREATE TABLE
regression=# drop function myabs(int);
ERROR:  cannot drop function myabs(integer) because other objects depend on it
DETAIL:  table foo depends on function myabs(integer)
HINT:  Use DROP ... CASCADE to drop the dependent objects too.

Unfortunately, there's still no dependency on the column f1 in this
scenario.  That means any function that wants to reconstruct the
correct dependencies would need a way to scan the partition expressions
for Vars.  Not much fun from plpgsql, for sure.

			regards, tom lane