On Wed, Sep 4, 2019 at 2:36 PM Amit Langote <amitlangote09@gmail.com> wrote:
>
> Hi,
>
> Maybe I'm forgetting some dependency management discussion that I was
> part of recently, but is the following behavior unintentional?
>
> create table p (a int, b int, c int) partition by list (a);
> create table p1 partition of p for values in (1) partition by list (b);
> create table p11 partition of p1 for values in (1);
> create index on p (c);
> alter table p drop column c;
> ERROR: cannot drop index p11_c_idx because index p1_c_idx requires it
> HINT: You can drop index p1_c_idx instead.
>
> Dropping c should've automatically dropped the index p_c_idx and its
> children and grandchildren, so the above complaint seems redundant.
Interestingly, this behavior only occurs with v12 and HEAD. With v11:
create table p (a int, b int, c int) partition by list (a);
create table p1 partition of p for values in (1) partition by list (b);
create table p11 partition of p1 for values in (1);
create index on p (c);
alter table p drop column c; -- ok
Note that the multi-level partitioning is not really needed to
reproduce the error.
I think the error in my first email has to do with the following
commit made to v12 and HEAD branches earlier this year:
commit 1d92a0c9f7dd547ad14cd8a3974289c5ec7f04ce
Author: Tom Lane <tgl@sss.pgh.pa.us>
Date: Mon Feb 11 14:41:13 2019 -0500
Redesign the partition dependency mechanism.
There may not really be any problem with the commit itself, but I
suspect that the new types of dependencies (or the way
findDependentObject() analyzes them) don't play well with inheritance
recursion of ATExecDropColumn(). Currently, child columns (and its
dependencies) are dropped before the parent column (and its
dependencies). By using the attached patch which reverses that order,
the error goes away, but I'm not sure that that's the correct
solution.
Tom, thoughts?
Thanks,
Amit
