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

[Nicklas Aven]

Thanks a lot Regina
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 :)

/Nicklas


----- Ursprungsmeddelande -----
> 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/6c51034e/attachment.html>