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

[Stephen Frost]

* Paragon Corporation (lr at pcorp.us) wrote:
> 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.

I'm not sure that I really see it as leading to any actually undefined
or unintuitive behavior..

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

If you have a well-defined type+typmod on the parent table, it'd work
the same way as you expect.  The only case where this would be different
is if you had the same *type* but a less-constrainted typmod on the
parent then you could have a more-constrainted typmod on the child.

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

This is more-or-less akin to asking that you structure things like:
NUMERIC mynum
CHECK (floor(mynum) = mynum)

and then asking PG to represent that column in the database catalogs as
being 'NUMERIC(18,0)' or something like that.  We should not be using
CHECK constraints as the basis of what the typmod on a column is.
You're welcome to define the column as geometry and put whatever CHECK
constraints you want on it, but don't go changing what that ends up
looking like in the (more-or-less) catalog.  What happens when you drop
and recreate that constraint for some reason, and someone else looks at
the column in the middle of that operation?

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

That's more-or-less exactly the case which would be nice to handle, but
I don't see it happens.  It's not like we don't know when returning from
ST_intersection what the geometry of the result is.  If we didn't, how
in the world could we sensibly return *anything*?  We don't know going
in, of course, and right now PG *has* to know going in, but who knows,
maybe that'll change some day.

We already have *some* support for this kind of notion, through the
ANYARRAY type.

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

Right, exactly, we have lots of situations like this and we have to try
to cast them all today to what the caller *thinks* the answer is.  If
the caller ends up trying to force a cast which doesn't match what
st_intersection ends up returning, they're likely to get a suprising
error..

> For some we could like ST_Centroid.

Not really..  There's a column issues here, based on the docs:
the SRID matches that which goes in and couldn't be defined for the
entire function, and it can return an empty geometrycollection.  Now, I
don't really see why an empty geometrycollection should be returned, as
I would think NULL or an error would be more appropriate, but if we want
to exactly match what the current behavior is we'd have to deal with
that.

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

Isn't think more-or-less what anyarray and friends do?  Not sure if
that's currently only available in core pieces or if that could be
extended to an external module, but I do like the idea.

> Or that it always returns a specific type regardless of what went in.  

Well, this we can do to some extent...  I would have expected that you
could specify the typmod on a return type for a function, but I have to
admit that I don't ever recall trying to.

	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/2199116d/attachment.sig>