Re: dropping column prevented due to inherited index

Hi Ashutosh,

On Mon, Oct 7, 2019 at 1:39 PM Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)com> wrote:
> I think we could have first deleted all the dependency of child object
> on parent and then deleted the child itself using performDeletion().

So, there are two objects to consider in this case -- column and an
index that depends on it.

For columns, we don't store any dependency records for the dependency
between a child column and its corresponding parent column. That
dependency is explicitly managed by the code and the attinhcount flag,
which if set, prevents the column from being dropped on its own.

Indexes do rely on dependency records for the dependency between a
child index and its corresponding parent index. This dependency
prevents a child index from being dropped if the corresponding parent
index is also not being dropped.

In this case, recursively dropping a child's column will in turn try
to drop the depending child index. findDependentObject() complains
because it can't allow a child index to be dropped, because it can't
establish that the corresponding parent index is also being dropped.
That's because the parent index will be dropped when the parent's
column will be dropped, which due to current coding of
ATExecDropColumn() is *after* all the child columns and indexes are
dropped. If we drop the parent column and depending index first and
then recurse to children as my proposed patch does, then the parent
index would already have been dropped when dropping the child column
and the depending index.

> As an example let's consider the case of toast table where we first
> delete the dependency of toast relation on main relation and then
> delete the toast table itself otherwise the toast table deletion would
> fail. But, the problem I see here is that currently we do not have any
> entry in pg_attribute table that would tell us about the dependency of
> child column on parent.

I couldn't imagine how that trick could be implemented for this case. :(

Thanks,
Amit