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

[Stephen Frost]

* PostGIS (trac at osgeo.org) wrote:
>  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

So the top-level table must have a 'plain' geometry column, yes, as the
data returned from it can include different types of gemoetries?  So,
the concern here is that PG is going to force the top-level table and
the child tables to have the exact same type (including typmod)?  That
sounds like something which should be fixed in PG itself (if, indeed,
it's actually broken).

Consider the case where you might want child tables with specific
NUMERIC(X,Y) options, but the top-level could just have NUMERIC.  Of
course, this would have to be validated by PG in some way (a call into
some type-specific function at the time of the inheiritance which checks
if the top-level type is a valid generalization of the child table
type).  Having a side table or having to look at constraints or
something is certainly not the 'right' solution here.

>  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.  

Rebuilding views like that might be something which could be done using
a script during the upgrae process.  Of course, longer-term, it'd be
nice if there was a way for PG to support functions returning a
different typmod than what went in, but that's not likely to happen any
time soon.

	Thanks,

		Stephen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20110522/c772f26a/attachment.sig>