[postgis-devel] Re: Search Path and Function Overloading

[Paul Ramsey]

Paolo,

This is perhaps best discussed on postgis-devel. I do not know that 
there is any good/easy answer. I would like to most all our functions to 
st_* space at some point, but that is a huge backward-compatible break, 
and if we leave in backwards-compatible hooks, your problem remains.

P

Paolo Cavallini wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Ciao Paul,
> we encountered a problem with some postgis functions, in particular for
>  area(geometry) and length(geometry), but it could involve also other
> functions (isclosed?).
> - From what we have understood
> (http://www.postgresql.org/docs/8.2/interactive/xfunc-overload.html),
> Postgresql supports function overloading, thus when there are two
> functions with the same name, it chooses on the basis of the parameters
> required.
> In the case of area and length:
> in postgres we have
> area(object)    double precision       area(box '((0,0),(1,1))')
> length(object)    double precision     length (path '((-1,0),(1,0))')
> 
> in postgis
> Area(geometry)
> Returns the area of the geometry if it is a polygon or multi-polygon.
> Length(geometry)
> The length of this Curve in its associated spatial reference.
> synonym for length2d()
> OGC SPEC 2.1.5.1
> 
> Therefore, the two functions should accept different parameters to be
> consistently applied. Unfortunately, the geometry data type is ok for
> both, and this may create confusion.
> 
> In practice, if the user instlls postgis in a db and uses
> area(the_geom), she gets the area of the polygon (ok). But if one
> creates a new schema, loads geodata and
> 
> set search_path to nuovoschema;
> 
> then
> 
> select area(the_geom) from nometable;
> 
> postgres uses its function, not the postgis one, so the user gets a
> different result from the expected.
> ex:
>      zona     |     area
> - --------------+---------------
>  sperimentale | 15596054.0625
>  controllo    |   11489052.75
> 
> where
> select public.area(the_geom) from nometable;
> gives instead:
>      zona     |       area
> - --------------+------------------
>  sperimentale | 7824232.73876953
>  controllo    | 6047695.49169922)
> 
> We do not know if this is a known problem, and what could be a good
> solution. One could change the function area(geometry) to require an
> additional parameter, univoquely geographic. In this case one would get
> (when in the schema)an error :
> function area(geometry...) does not exist).
> HINT:  No function matches the given name and argument types. You may
> need to add explicit type casts)
> (much better than an incorrect result).
> We do not know, however, whether this could cause problems with OGC
> standards or anything else (other than breaking backwards compatibility).
> When you know the problem it is not so bad (setting search_path to
> schemaname, public), but before realizing this many errors could have
> been done. A first step could be to point this out clearly in the man?
> Sorry for bothering.
> All the best.
> pc and lia
> - --
> Paolo Cavallini
> email+jabber: cavallini at faunalia.it
> www.faunalia.it
> Piazza Garibaldi 5 - 56025 Pontedera (PI), Italy   Tel: (+39)348-3801953
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iD8DBQFF6Gmw/NedwLUzIr4RArVPAKCt7vPNXOOgIIgV/2o2H/YuhrACzQCfekvX
> HSu+cp+k7ZhiBoBqZjR/wZo=
> =svPt
> -----END PGP SIGNATURE-----


-- 

   Paul Ramsey
   Refractions Research
   http://www.refractions.net
   pramsey at refractions.net
   Phone: 250-383-3022
   Cell: 250-885-0632