Re: Column/type dependency recording inconsistencies

On 09/11/14 23:04, Tom Lane wrote:
> but sure enough:
>
> d1=# drop extension deptestext;
> ERROR: cannot drop extension deptestext because other objects depend on it
> DETAIL: table testtable column undroppablecol2 depends on type undroppabletype
> table testtable column undroppablecol1 depends on type undroppabletype
> HINT: Use DROP ... CASCADE to drop the dependent objects too.
>
> I suspect this is actually a bug in the dependency search logic in DROP.
> Don't have the energy to chase it right now though.
>

Yes that's where I started searching also and yes it is. The actual
situation is that the columns of the table that is about to be dropped
are normally not added to the object list that is used for dependency
checks (if the table is going to be dropped who cares about what column
depends on anyway).
But this logic depends on the fact that the columns that belong to that
table are processed after the table was already processed, however as
the new type was added after the table was added, it's processed before
the table and because of the dependency between type and columns, the
columns are also processed before the table and so they are added to the
object list for further dependency checking.

See use and source of object_address_present_add_flags in dependency.c.

I am not really sure how to fix this, other than changing this to two
step process - essentially go through the resulting object list again
and remove the columns that already have table there, but that's not
exactly super pretty solution.

--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services