<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">

<html><head>

    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">

    <meta name="generator" content="Osso Notes">

    <title></title></head>

<body>

<p>Thanks a lot Regina

<br>this actually clearafied a lot. I have never thought about that postgresql actually knows what type from what schema is used to define a column. That makes sense and makes my idea of approach quite worthless. Then I think, when it is not possible to just have one dataset handled fully from different dpostgis versions, that I instead makes it totally different. to be really wild I could have a cutting egde version with postgresql 9.0 beta and geos and postgis trunk. Wouldn't that quite cool :)

<br>

<br>/Nicklas

<br>

<br>

<br>----- Ursprungsmeddelande -----

<br>> Nicklas,

<br>> 

<br>> public.geometry and trunk.geometry are NOT the same type as far as

> PostgreSQL is concerned.

<br>> 

<br>> With that said I suspect your ST_Area... etc. functions in trunk are bound

<br>> to public.geometry and not trunk.geometry, but your ST_SRID in trunk is

<br>> against trunk.geometry.

<br>> 

<br>> Scanning your information_schema.  Your table geometry is defined as

<br>> public.geometry.

<br>> 

> How could this happen.  I suspect the sequencing in the install script.

<br>> That when ST_SRID was created trunk.geometry existed so it grabbed unto that

> since it was higher in search path.

<br>> 

<br>> ST_Area etc. perhaps when they were created trunk.geometry did not exist so

<br>> they got tied to public.geometry. (normally if these don't exist, you see a

<br>> 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).

<br>> 

<br>> Given that.  The downside of your approach is if you are going to install

<br>> like this, you need to strip out all the trunk.geometry/operator functions

> to prevent this data type from being created.

<br>> 

<br>> Alternatively keep two sets of data - one against public.geometry and one

> against trunk.geometry.  Which sounds messy.

<br>> 

<br>> Hope that helps,

<br>> Regina

<br>>

<br>>    _____ 

<br>>

<br>> From: <a href="mailto:postgis-devel-bounces@postgis.refractions.net">postgis-devel-bounces@postgis.refractions.net</a>

<br>> [<a href="mailto:postgis-devel-bounces@postgis.refractions.net">mailto:postgis-devel-bounces@postgis.refractions.net</a>] On Behalf Of Nicklas

<br>> Avén

<br>> Sent: Wednesday, May 12, 2010 7:00 PM

<br>> To: PostGIS Development Discussion

<br>> Subject: [postgis-devel] searching for geometry type in wrong schema

<br>>

<br>>

<br>> Hallo

<br>>

> I have bumped into something very strange I think.

<br>> I am trying to get postgisonline.org work smoothly with multiple versions of

<br>> postgis.

<br>>

<br>> The solution I am now trying I guess is somewhere in the outer parts of what

<br>> 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.

<br>>

<br>> Because of that I have installed postgis 1.5.1 in public schema as usual and

<br>> Postgis trunk in a schema called trunk. Then I have different users with

<br>> different search_path and decide what version to use by changing connection

<br>> parameters.

<br>> This worked just great until a removed public schema from the search_path

<br>> for the trunk version. Then some functions stopped working with the error,

<br>> for instance:

<br>>

<br>> function ST_Srid(public.geometry) does not exist

<br>>

<br>> What is strange is that ST_Area works fine and ST_Distance and ST_Length,

<br>> but not ST_Dump

<br>>

<br>> The question I don't understand right now is what decides where to get the

<br>> type. From what I understand ST_Srid reads the type from the public schema

<br>> and complains that the ST_Srid function in the trunk schema doesn't like the

<br>> public.geometry type. I also guess that ST_Area does what is expected and

<br>> uses the geometry type specified in the trunk schema and the ST_Area

<br>> function get satisfied since it expects ST_Area(trunk.geometry)

<br>>

<br>> My first thought is that there is some hard coded path to public schema in

<br>> some functions. But I really don't know because in my local install, not

<br>> postgisonline, I get different result. First all seemed to work and now

> nothing seems to work.

<br>>

<br>> 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.

<br>>

<br>> If you want to see the phenomena on postgisonline you can get the trunk

<br>> search_path by using this address:

<br>> <a href="http://www.postgisonline.org/map.php?version=trunk">http://www.postgisonline.org/map.php?version=trunk</a>

<br>>

<br>> then you can try against a table called roads. All queries producing a

<br>> geometry column called the_geom will give an error because there is an srid

> check which causes the error above.

<br>>

<br>> but try

<br>> Select ST_Length(the_geom) from roads;

<br>> or

<br>> Select ST_Area(the_geom) from property;

<br>> and it should work. But :

<br>> Select ST_Srid(the_geom) from roads;

<br>>  will give error

<br>>

<br>> Any ideas?

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

<br>>

<br>> Thanks

<br>> Nicklas

<br>>

<br><br></p>

</body>

</html>