[postgis-devel] searching for geometry type in wrong schema

[Paragon Corporation]

Nicklas,
 
public.geometry and trunk.geometry are NOT the same type as far as
PostgreSQL is concerned.
 
With that said I suspect your ST_Area... etc. functions in trunk are bound
to public.geometry and not trunk.geometry, but your ST_SRID in trunk is
against trunk.geometry.
 
Scanning your information_schema.  Your table geometry is defined as
public.geometry.
 
How could this happen.  I suspect the sequencing in the install script.
That when ST_SRID was created trunk.geometry existed so it grabbed unto that
since it was higher in search path.
 
ST_Area etc. perhaps when they were created trunk.geometry did not exist so
they got tied to public.geometry. (normally if these don't exist, you see a
creating shell for geometry type -- that's what all that means.  In this
case it didn't need to create a shell since it was already present).
 
Given that.  The downside of your approach is if you are going to install
like this, you need to strip out all the trunk.geometry/operator functions
to prevent this data type from being created.
 
Alternatively keep two sets of data - one against public.geometry and one
against trunk.geometry.  Which sounds messy.
 
Hope that helps,
Regina

  _____  

From: postgis-devel-bounces at postgis.refractions.net
[mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of Nicklas
Avén
Sent: Wednesday, May 12, 2010 7:00 PM
To: PostGIS Development Discussion
Subject: [postgis-devel] searching for geometry type in wrong schema


Hallo

I have bumped into something very strange I think. 
I am trying to get postgisonline.org work smoothly with multiple versions of
postgis.

The solution I am now trying I guess is somewhere in the outer parts of what
is recommended but I have found that the easiest administration of the
datasets to use in postgisonline is if everything is in the same database. 

Because of that I have installed postgis 1.5.1 in public schema as usual and
Postgis trunk in a schema called trunk. Then I have different users with
different search_path and decide what version to use by changing connection
parameters. 
This worked just great until a removed public schema from the search_path
for the trunk version. Then some functions stopped working with the error,
for instance:

function ST_Srid(public.geometry) does not exist

What is strange is that ST_Area works fine and ST_Distance and ST_Length,
but not ST_Dump

The question I don't understand right now is what decides where to get the
type. From what I understand ST_Srid reads the type from the public schema
and complains that the ST_Srid function in the trunk schema doesn't like the
public.geometry type. I also guess that ST_Area does what is expected and
uses the geometry type specified in the trunk schema and the ST_Area
function get satisfied since it expects ST_Area(trunk.geometry)

My first thought is that there is some hard coded path to public schema in
some functions. But I really don't know because in my local install, not
postgisonline, I get different result. First all seemed to work and now
nothing seems to work.

This is of course a very small issue and there is workarounds, but if this
is a bug it might give other unexpected behaviours I guess.

If you want to see the phenomena on postgisonline you can get the trunk
search_path by using this address:
http://www.postgisonline.org/map.php?version=trunk

then you can try against a table called roads. All queries producing a
geometry column called the_geom will give an error because there is an srid
check which causes the error above.

but try 
Select ST_Length(the_geom) from roads; 
or
Select ST_Area(the_geom) from property;
and it should work. But :
Select ST_Srid(the_geom) from roads;
 will give error

Any ideas?
Is it a PostgreSQL bug or a PostGIS bug or am I the bug myself?

Thanks
Nicklas

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20100513/d666f744/attachment.html>