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

[Tom Lane]

Mark Cave-Ayland <mark.cave-ayland at siriusit.co.uk> writes:
> Paul Ramsey wrote:
>> What happens when someone runs a UPDATE table SET
>> geom=setsrid(geom,400) ? Will that be (a) allowed and (b) reflected in
>> the metadata after it is done? If not then the usefulness of the
>> change begins to fall off precipitately.

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

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.

>   So the theory goes that if we can create a CAST between geometry and 
> geometry then we should be good. Tom, is this something that is actually 
> supported/possible?

The code refers to it as a "length coercion function" because all the
standard cases are enforcing something length-like.  But you can
interpret your typmods however you want, modulo the negative/positive
restriction.

			regards, tom lane