CREATE TABLE cities ( city_id bigserial not null, name text not null, population int
) PARTITION BY LIST (initcap(name));
CREATE TABLE cities_west PARTITION OF cities ( CONSTRAINT city_id_nonzero CHECK (city_id != 0)
) FOR VALUES IN ('Los Angeles', 'San Francisco') PARTITION BY RANGE (population);
CREATE TABLE cities_west_10000_to_100000 PARTITION OF cities_west FOR VALUES FROM (10000) TO (100000);
You can only create an index in cities_west_10000_to_100000 because postgresql assumes that cities_west is also a partitioned table. So the implementation looks correct, despite the fact that there are no tests around it.
I have concerns regarding the fix, As you negate the condition, Before the fix it was not displaying Index node for Tables but after the fix it will not display it for Partition tables.
But when I read the Postgres docs it say,
Partitions may themselves be defined as partitioned tables, using what is called sub-partitioning. Partitions may have their own indexes, constraints and default values, distinct from those of other partitions. Indexes must be created separately for each partition. SeeCREATE TABLE for more details on creating partitioned tables and partitions.
Yes that is correct, but it's about Partitions(child tables), not the *Partitioned* table. We are showing indexes on Partitions. Please refer "Index_on_Partitioned_table.png"
Please find the attached patch to fix RM #3180Index node is missing from the tree view of the table node. This is a regression of one of the older commit.