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

[Paragon Corporation]

> 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).
I don't think it's anything that needs fixing in fact I would consider it a
bug if it didn't work that way.

Correct -- just verified with this

CREATE TABLE test_parent (geog geography);
CREATE TABLE test(geog geography(POINT));
ALTER TABLE test INHERIT test_parent;

Gives error:
ERROR:  child table "test" has different type for column "geog"

The reason why it doesn't need fixing and is the way it should be is for
most use cases I rely on these catches.  Note most use cases, I need my
types to be exactly the same (and exactly the same I mean unconstrained
exactly the same in some cases).  For postgres to not enforce this I would
consider too much ambiguous guessing of what my intent was.

So when I try add a table in an inheritance hierarchy it saves me when I
screwed up on defining a type.  So I consider the check a necessary evil.

> Having a side table or having to look at constraints or something is
certainly not the 'right' solution here.
Why is looking at constraints bad?  They are stored in the catalogs as well
and not all that much harder to parse out especially since we name them
consistently (since these cases they were added with addgeometrycolumn)


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

That doesn't make too much sense  to me for PostgreSQL to do that (unless I
misunderstood what you meant).   Take the example of ST_Intersection where
what comes out can be who the heck knows except you.
As the designer of the system I can most often know what the output type
will be if it is one specific type.  There wouldn't be any way for
PostgreSQL to know that without inspecting the data which would be mighty
slow
Or developing some sentient quality.

In fact pretty many of the functions we have are like that.  E.g
ST_Transform -- what comes out is the same geometry type that went in but we
can't say ST_Transform returns POINT or whatever.
For some we could like ST_Centroid.

That does get me thinking -- 

In that mind set -- it would be nice if we could specify that a function
always returns the same type as what went in
Or that it always returns a specific type regardless of what went in.  

That would be pretty sweet and handle most of the interpretting view types
transparently.