Re: 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