Re: [HACKERS] dropping partitioned tables without CASCADE

>
> I used a slight modification of the case mentioned on the docs. I
> confirm this fails repeatably for me on current HEAD.
>
> CREATE TABLE cities (
>      city_id      bigserial not null,
>      name         text not null,
>      population   bigint
> ) PARTITION BY LIST (left(lower(name), 1));
>
> CREATE TABLE cities_ab
> PARTITION OF cities (
>   CONSTRAINT city_id_nonzero CHECK (city_id != 0)
> ) FOR VALUES IN ('a', 'b')
> PARTITION BY RANGE (population);
>
> drop table cities;
> ERROR:  cannot drop table cities because other objects depend on it
> DETAIL:  table cities_ab depends on table cities
> HINT:  Use DROP ... CASCADE to drop the dependent objects too.

I think that's what this patch fixes. Do you see this behaviour after
applying the patch?

>
> I notice also that
>   \d+ <tablename>
> does not show which partitions have subpartitions.

I will confirm this once I have access to the code.

>
> I'm worried that these things illustrate something about the catalog
> representation that we may need to improve, but I don't have anything
> concrete to say on that at present.

AFAIK, catalogs have everything needed to fix this; it's just the
matter to using that information wherever it's needed.
-- 
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company