[postgis-devel] Re: [postgis-users] create tables smarter

[Markus Schaber]

Hi, Tom,

Tom Lane <tgl at sss.pgh.pa.us> wrote:

> > I think the way to think about this is to look again at the varchar() 
> > example. In the case of a varchar(255) field, then the typmod could be 
> > considered to be a column constraint involving string length. So this 
> > would suggest that what we would need to do is alter the CHECK 
> > constraint on a geometry table to compare the table typmod with each 
> > geometry and throw an ERROR on mismatch.
> 
> Yeah, if the semantics you want are that the column typmod is a
> constraint on which geometries are allowed in the column, then it's
> pretty easy to do this via typmod.  A negative typmod is always
> interpreted as "no constraint".

Is it possible for functions and operators to change the typmod?

e. G. toUpper() does not change the string length, string concatenation
does.

We have the problem that e. G. scaling or translating does not change
the typemod, while intersection will need to "broaden" the type of
geometry, or force2d will change the dimensional part.

> Are you going to be interested in partial constraints, eg enforce
> 3-D but allow multiple SRIDs?  If so, you'll need to leave a "don't
> care" value for each subfield so you can have a positive typmod
> value that indicates constraints on only some of the properties.

Yes, and setSrid() will return geometries with a different typemod than
the input geometries, possibly.


For normal selects, typemods don't matter so much, but CREATE TABLE AS
SELECT or CREATE VIEW are different.




Regards,
Markus

-- 
Markus Schaber | Logical Tracking&Tracing International AG
Dipl. Inf.     | Software Development GIS

Fight against software patents in Europe! www.ffii.org
www.nosoftwarepatents.org