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