[postgis-devel] pgsql 7.3

Dave Blasby dblasby at refractions.net
Mon Aug 19 09:39:01 PDT 2002


redmonde at purdue.edu wrote:
> 
> I'm running a very current (as of yesterday) pgsql development version 7.3. I'm not sure if any developers are keeping up on recent postgres, but it seems that plpgsql changes have affected postGIS.
> 
> 1: The test in the readme file does not work as said in casting. Doing:
> SELECT * from geom_test WHERE geom && 'BOX3D(2 2 0,3 3 0)'::box3d; replys:
> Unable to identify an operator '&&' for types 'geometry' and 'box3d'
> but SELECT * from geom_test WHERE geom && 'BOX3D(2 2 0,3 3 0)'::geometry; works.
> 
> 2: SELECT AddGeometryColumn('test','geotest','geopoint',1,'POINT',2); returns:
> WARNING:  Error occurred while executing PL/pgSQL function addgeometrycolumn
> WARNING:  line 50 at execute statement
> ERROR:  copyObject: don't know how to copy node type 506
> 
> I'm not sure if these changes are bugs with postgis 0.7.1 or because of internal changes in the upcomming plpgsql. I'd like to know if any developers have looked into this?

Hum, I dont think anyone here has tried out 7.3 yet (heck, we just moved
to 7.2 a few months ago).

I have heard that they did make some type casting changes - PostGIS does
rely on Postgresql automagically casting BOX3Ds to and from GEOMETRIES.

When you do something like 'BOX3D(2 2 0,3 3 0)'::geometry, you directly
create a GEOMETRY without any real geometry, just the bounding volume
that's attached to every geometry.  The only reason this exists is for
indexing - its more difficult to directly index a type with a different
type, so I cheat ...

Doing "...WHERE geom && 'BOX3D(2 2 0,3 3 0)'::box3d" will create a BOX3D
object, then convert this BOX3D object to a GEOMETRY without any real
geometry (exactly like above).  This convesion is automagically detected
by postgresql - postgresql will see a function that takes a GEOMETRY as
an argument, but is actually given a BOX3D.  It will then look for a
function that converts a BOX3D into a GEOMETRY.  Imagine this 'smarts'
has been dumbed down in 7.3 to clear up some other issues.

I think I've fixed the postgis.sql.in file for 7.3 - the work around for
these problems is to just explictly replace '::box3d' with
'::geometry'.  I'll try to find out what the postgresql developers have
done - was there anything in the README?

dave




More information about the postgis-devel mailing list