Opened 8 years ago
Closed 8 years ago
#3766 closed defect (fixed)
geometry_columns and raster_columns views do not list parent partitioned tables of PostgreSQL 10
Reported by: | robe | Owned by: | robe |
---|---|---|---|
Priority: | blocker | Milestone: | PostGIS 2.4.0 |
Component: | postgis | Version: | master |
Keywords: | postgresql 10 | Cc: |
Description (last modified by )
One of the new features of PostgreSQL 10 is declaritive partitioning.
Unfortunately it seems a parent partition table is not caught by our views though interestingly the child partitions are.
Here is an example that exercises the issue:
CREATE TABLE pgis_parent_part ( id int GENERATED BY DEFAULT AS IDENTITY, geom geometry(point), geog geography(point), rast raster ) PARTITION BY RANGE (id); CREATE TABLE pgis_parent_part_child_1 PARTITION OF pgis_parent_part FOR VALUES FROM (unbounded) TO (unbounded);
Now if you do select from the various tables, you should have 2 records, but get back only one.
SELECT f_table_name AS t, f_geometry_column AS gc FROM geometry_columns;
t | gc --------------------------+------ pgis_parent_part_child_1 | geom (1 row)
SELECT r_table_name AS t, r_raster_column AS gc FROM raster_columns;
t | gc --------------------------+------ pgis_parent_part_child_1 | rast (1 row)
— however geography does
SELECT f_table_name AS t, f_geography_column AS gc FROM geography_columns;
t | gc --------------------------+------ pgis_parent_part | geog pgis_parent_part_child_1 | geog (2 rows)
Not sure what makes geography_columns different from raster_columns and geometry_columns. I'm guessing it might be some sort of permission check we are doing perhaps in raster and geometry that we aren't doing in geography_columns.
FWIW, it's not just us. I notice in pgAdmin3 and pgADmin 4 (version 1.4), I can't see the parent partitions listed in the table tree.
Change History (4)
comment:1 by , 8 years ago
Description: | modified (diff) |
---|
comment:2 by , 8 years ago
Description: | modified (diff) |
---|
Okay it looks like our raster_columns and geometry_columns do a pg_class.relkind check while geography does not and partitioned tables are of relkind = 'p', a new kind of relkind beast.
If I take the relkind check out, I get stuff that aren't tables like raster helper types and geometry helper types. So we need the check and should probably have it for geography as well. We just don't happen to have any geography helper types that contain geography as a subcomponent, but if we introduce ST_Dump for geography, that would change.