[postgis-devel] Typmod Enforcement

[Kevin Neufeld]

Personally,  I agree with David for the exact reason he mentioned.  
Avoid autoconversions / autocasting / 
auto-what-just-happened-with-my-data?  Be explicit, but provide 
convenience functions for easy casting or conversions ... which we 
already have (ST_Force_2D, ST_Force_3D, ST_Force_3DM,...)

So my two cents are to complain rather than insert (with warnings).

As for the parameter sequence, my vote is ( type, [srid] ) for the 
reasons you outlined Paul.

-- Kevin

Paul Ramsey wrote:
> Having now figured out the magic of typmod enforcement, there's an 
> interesting "extra feature" available that old fashioned constraint 
> enforcement didn't provide: if we want we can coerce bad data into 
> good data during the enforcement stage.
>
> Here's as example:
>
> If I have a column with type POINTZ and I feed it a POINT, there's not 
> much I can do -- the input is lacking sufficient information. However, 
> if I have a column with type POINT and feed it a POINTZ, I have the 
> option of stripping the input down to the column dimensionality. The 
> PgSQL code for things like varchar() tosses errors on overlong input, 
> except when the spare stuff is white space, in which case it truncates.
>
> So, in that example, information would be discarded in the coercion 
> which I probably couldn't convince you to do. But what about this?
>
> If I have a column with SRID = 4326 and try to insert an object with 
> SRID = 26910. I can coerce it into the right SRID with no data loss. 
> Do I insert or complain?
>
> P.
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel