[postgis-devel] RC5 problem

[Carl Anderson]

possibly too late in the development cycle for this discussion.

strk at refractions.net wrote:

>This should be the behaviour since RC1.
>Note that box3d is double precision, while box2d is
>single precision. So you can choose which one to use.
>Example:
>
>strk=# select xmin('POINT(1.0000000001 0)'::geometry::box3d);
>     xmin
>--------------
> 1.0000000001
>(1 row)
>
>strk=# select xmin('POINT(1.0000000001 0)'::geometry::box2d);
> xmin
>------
>    1
>(1 row)
>  
>

I am willing to be convinced ... but

If xmin (<box3d>) existed
and xmin(<box3d>) was removed

the same result could be accomplished by

select xmin('POINT(1.0000000001 0)'::geometry);
     xmin
--------------
 1.0000000001
(1 row)


and using the implicit box2d -> box3d cast
select xmin('POINT(1.0000000001 0)'::geometry::box2d);

 xmin
------
    1
(1 row)


you can still choose the precision level and undiscriminating users just get an answer without thinking.

>Also note that geometry::box3d always *computes* the bounding
>box while geometry::box2d uses the bbox cache if available
>(which is the single-precision version).
>
>  
>
There are obviously internal performance issues that effect the 
backend.  I am (in this discussion)
thinking about userspace where in 0.9 and prior versions they could use 
xmin(<geometry>) and now must
declare a casting type.  Code will be broken, someone will have to 
explain what changed, why it
changed and how to correct the code.  Could'nt the internal issues be 
dealt with a
private function or xmin2d() and leave the user experience as similar as 
possible to prior versions.

To me this is different from the QGIS issue, as geometry() is part of 
the OGC SF-SQL spec and
rejecting non conforming WKT is good.  xmin() and its kin are vendor 
specific extensions
so you have more latitude.

C.