[postgis-devel] [PostGIS] #944: typmod support for PostGIS geometry

[PostGIS]

#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
 Reporter:  robe         |       Owner:  pramsey      
     Type:  enhancement  |      Status:  new          
 Priority:  medium       |   Milestone:  PostGIS 2.0.0
Component:  postgis      |     Version:  trunk        
 Keywords:               |  
-------------------------+--------------------------------------------------

Comment(by robe):

 Paul,
 I thought about another way of doing this that perhaps won't be quite as
 offensive to you and Mark and won't require a side-line table.

 First to summarize, typmod doesn't work in some of my use cases like the
 example I described where I have an inheritance model like
   features (people query from here if they want all types)
     features_poly (here for just polys and so forth)
     features_point
     features_lines

 However for those child tables, I still have srid and geometry type
 constraints on them which can be read from the constraints catalogs.  So
 my second proposition is:

 Forget about the side line table, but have geometry_columns check both
 typmod and constraints.  I think it might be slightly slower, but
 definitely faster than what I think QGIS does of inspecting all the tables
 with geometries (when you choose check all tables).

 This would solve my other issue of when I restore my data schema over a
 new version of postgis having to repopulate my geometry_columns table.

 Now for views -- sadly I think people would have to rebuild some of their
 views with a geometry typmod cast so that they are properly registered in
 the catalogs.  I don't think that's bad though because you can be assured
 your geometry_columns is always consistent with your view without having a
 second registration step.  The number of views people have to put a typmod
 on is few.  The reason being is that unless you are applying a function to
 the geometry column, PostgreSQL uses the underlying table type for the
 type of the column.  So even view people should be happier.

 As far as strk's need -- I think that is best served with something else.
 Additional columns aren't defined in SQL/MM nor geometry_columns and I
 don't think we should introduce foreign things like that.  Perhaps another
 table like geometry_columns_more_detail (well can't think of a name) --
 that would just have the additional meta data and then a view that joins
 the geometry_columns with this table will suffice.  Heck since we can make
 view updatable we can easily create such a left join thing and would only
 require filling in the additional information not present in
 geometry_columns.

-- 
Ticket URL: <http://trac.osgeo.org/postgis/ticket/944#comment:22>
PostGIS <http://trac.osgeo.org/postgis/>
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.