[PostGIS] #223: Breaking change ST_Extent returns a box3d_extent object

[PostGIS-4]

#223: Breaking change ST_Extent returns a box3d_extent object
---------------------+------------------------------------------------------
 Reporter:  robe     |       Owner:  pramsey      
     Type:  defect   |      Status:  new          
 Priority:  medium   |   Milestone:  postgis 1.4.0
Component:  postgis  |     Version:              
 Keywords:           |  
---------------------+------------------------------------------------------
 I've been testing 1.4 on some  production apps for the past couple of days
 and ran into one breaking change.

 Since our ST_Extent now returns a box3d_extent, this broke one of my
 custom functions that was expecting a box2d

 To fix, I had to make a change to my app to accept box3d instead of box2d
 in the function call, but I also had to put in an auto cast

 CREATE CAST (box3d_extent AS box3d)
   WITH FUNCTION st_box3d_extent(box3d_extent)
   AS IMPLICIT;


 While this is not a bug, it is something that is likely to break some
 applications.  So I presume we should make note of it in the release
 notes.

--
Ticket URL: <http://trac.osgeo.org/postgis/ticket/223>
PostGIS <http://trac.osgeo.org/postgis/>
PostGIS
_______________________________________________
postgis-devel mailing list
postgis-devel@...
http://postgis.refractions.net/mailman/listinfo/postgis-devel

[PostGIS-4]

#223: Breaking change ST_Extent returns a box3d_extent object
----------------------+-----------------------------------------------------
  Reporter:  robe     |       Owner:  pramsey      
      Type:  defect   |      Status:  new          
  Priority:  medium   |   Milestone:  postgis 1.4.0
 Component:  postgis  |     Version:              
Resolution:           |    Keywords:              
----------------------+-----------------------------------------------------
Comment (by robe):

 On closer inspection, there are two things going on here.  I think our
 postgis_upgrade.sql is missing casts for box3d_extent.  I had two versions
 of this database. One I restored on top of a fresh 1.4 vanilla db and one
 I upgraded with the upgrade script.  I think its the one I upgraded that
 was missing the auto cast.  Though hmm I think the other one is giving a

 ERROR:  function get_coords(box3d_extent) is not unique
 LINE 6:        get_coords(ST_Extent(the_geom)) As acoord

 (because I have one function for geometry and one for box2d to handle the
 extent.) In that on. So I had to delete my box2d one and create nothing or
 create a box3d_extent.  Resulting in very sluggish performance (though
 that may be unrelated) Still need to investigate why its no longer using
 an index.

  I guess I'll have to retrace my steps on this one to figure out if this
 is just an isolated issue on my database.

--
Ticket URL: <http://trac.osgeo.org/postgis/ticket/223#comment:1>
PostGIS <http://trac.osgeo.org/postgis/>
PostGIS
_______________________________________________
postgis-devel mailing list
postgis-devel@...
http://postgis.refractions.net/mailman/listinfo/postgis-devel

[PostGIS-4]

#223: Breaking change ST_Extent returns a box3d_extent object
----------------------+-----------------------------------------------------
  Reporter:  robe     |       Owner:  pramsey      
      Type:  defect   |      Status:  new          
  Priority:  medium   |   Milestone:  postgis 1.4.1
 Component:  postgis  |     Version:              
Resolution:           |    Keywords:              
----------------------+-----------------------------------------------------
Changes (by pramsey):

  * milestone:  postgis 1.4.0 => postgis 1.4.1

--
Ticket URL: <http://trac.osgeo.org/postgis/ticket/223#comment:2>
PostGIS <http://trac.osgeo.org/postgis/>
PostGIS
_______________________________________________
postgis-devel mailing list
postgis-devel@...
http://postgis.refractions.net/mailman/listinfo/postgis-devel

[PostGIS-4]

#223: Breaking change ST_Extent returns a box3d_extent object
-------------------------+--------------------------------------------------
  Reporter:  robe        |       Owner:  pramsey      
      Type:  defect      |      Status:  closed      
  Priority:  medium      |   Milestone:  postgis 1.4.1
 Component:  postgis     |     Version:              
Resolution:  worksforme  |    Keywords:              
-------------------------+--------------------------------------------------
Changes (by pramsey):

  * status:  new => closed
  * resolution:  => worksforme

Comment:

 I'm not seeing this, and I am seeing the appropriate cast in the
 postgis.sql file.

--
Ticket URL: <http://trac.osgeo.org/postgis/ticket/223#comment:3>
PostGIS <http://trac.osgeo.org/postgis/>
PostGIS
_______________________________________________
postgis-devel mailing list
postgis-devel@...
http://postgis.refractions.net/mailman/listinfo/postgis-devel

[PostGIS-4]

#223: Breaking change ST_Extent returns a box3d_extent object
-------------------------+--------------------------------------------------
  Reporter:  robe        |       Owner:  pramsey      
      Type:  defect      |      Status:  closed      
  Priority:  medium      |   Milestone:  postgis 1.4.1
 Component:  postgis     |     Version:              
Resolution:  worksforme  |    Keywords:              
-------------------------+--------------------------------------------------
Comment (by robe):

 But its missing in the upgrade script.  Well the upgrade script needs a
 bit of work I suppose anyway.

 Try this for size on your virgin PostGIS 1.4/1.5 install to see what I
 mean?  Does it work for you?  This works in 1.3

 SELECT ST_Box3d(ST_Extent('POINT(1 2)'::geometry))

 I don't think there is much we can do about it and not sure how badly it
 affects people - so thought we should just note it.  It broke one of my
 apps is all.

--
Ticket URL: <http://trac.osgeo.org/postgis/ticket/223#comment:4>
PostGIS <http://trac.osgeo.org/postgis/>
PostGIS
_______________________________________________
postgis-devel mailing list
postgis-devel@...
http://postgis.refractions.net/mailman/listinfo/postgis-devel