[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 mcayland):

 In these cases, my responses would be:

 1) If we expect people tomove to PostGIS 2.0, there current tables built
 with AddGeometryColumn? should work as they did before. It would be
 painful to have them alter their geometry columns to typmod. With that
 said -- the postgresql catalog will be wrong for these geometries.

 This is something that could be automated as part of an upgrade. A script
 can be run to check the uniqueness of the geometry types within a table -
 if they are unique then we can update the catalog to represent the correct
 value, otherwise we set the typmod to be a generic GEOMETRY instead.

 And also - if we're going to make people do things like a dump/reload
 (which they will need with the new geometry format in 2.0) we might as
 well do other horrible things as part of the upgrade.

 2) For inheritance tables -- it is not unusual and I don't think bad
 practice to have each child have a separate geometry type (though it
 should have the same srid and dimension). typmod simply doesn't work for
 this model.

 Again, set the typmod to a generic GEOMETRY type but then add your own
 constraints on your child tables. I would say that mixing things in this
 way is an advanced level feature.

 3) There are varying degrees -- e.g. I think for example Oracle doesn't
 mind POLYGON/MULTIPOLYGON coexisting. Neither do ESRI Shapefiles. When you
 have a polygon in must cases it is more efficient to keep it that way than
 wrapping it in a multi wrapper. typmod doesn't work for this either.

 This one is more tricky - if it were me, I would just use MULTIPOLYGONS
 with one polygon for single shapes. When you say more efficient, what
 exactly do you mean here?

-- 
Ticket URL: <http://trac.osgeo.org/postgis/ticket/944#comment:13>
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.