> > 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers