[postgis-users] postgis.backend and legacy functions
Willy-Bas Loos
willybas at gmail.com
Wed Feb 24 10:35:09 PST 2016
OK, i've reproduced this on postgresql-9.4.6-1.pgdg70+1 with matching
client libraries (both plain dump and using pg_restore), but not on
postgresql-9.4.6-1.pgdg14.04+1
postgresql-9.4.6-1.pgdg14.04+1 will not install any of the old legacy
functions, stating
ERROR: attempt to redefine parameter "postgis.backend"
postgresql-9.4.6-1.pgdg70+1 will only state
WARNING: 'postgis.backend' is already set and cannot be changed until
you reconnect
and then create all the (probably bad) functions.
Here's how to reproduce:
1. log into a server that runs postgresql-9.4 and postgis 2.1 (but not
postgis 2.2)
2. create a database
3. create extension postgis
4. \i .../legacy.sql
5. make a dump of that
6. restore it on a server that runs postgresql-9.4.6-1.pgdg70+1 and
postgis 2.2
I can provide the dump file of step 5 if anyone wants it.
BUT i cannot reproduce the problems that i assume are caused by this (the
subject of this thread).
I only get a warning when using the function that refers to the old lib
(area instead of st_area)
I have verified that the server that has postgresql-9.4.6-1.pgdg70+1 (which
is where the actual problem occurred), was upgraded BEFORE the problem was
caused.
So something must have happened that caused the 'postgis.backend' to
change. And i changed it back later too, I am at a loss how this can come
about.
So if anyone has a clue please help.
In case anyone reads this ;P , how can i get the value in postgis.backend?
I've tried SHOW and SELECT, but that doesn't seem to work. Can't find docs
about it either, apart from this
<http://postgis.net/docs/manual-2.2/postgis_backend.html>.
leg=# select public.st_area(st_geomfromewkt('SRID=28992;POLYGON((100000
400000,100000 401000,101000 401000,101000 400000,100000 400000))'))
;
st_area
---------
1000000
(1 row)
leg=# select public.area(st_geomfromewkt('SRID=28992;POLYGON((100000
400000,100000 401000,101000 401000,101000 400000,100000 400000))'))
;
*WARNING*: 'postgis.backend' is already set and cannot be changed until
you reconnect
area
---------
1000000
(1 row)
leg=# SELECT distinct n.nspname||'.'||p.proname as function, p.probin --,
pg_get_function_identity_arguments(p.oid) AS params
FROM pg_proc p
JOIN pg_namespace n ON n.oid = p.pronamespace
WHERE p.proname in ('area', 'st_area');
function | probin
-----------------+---------------------
public.area | $libdir/postgis-2.1
pg_catalog.area |
public.st_area |
public.st_area | $libdir/postgis-2.2
(4 rows)
On Wed, Feb 24, 2016 at 5:41 PM, Willy-Bas Loos <willybas at gmail.com> wrote:
> I had suspected that i would be able to use either of both libraries,
> depending of what is in postgis.backend. But it's not like that.
> area(geometry) uses postgis-2.1
> and st_area(geometry) uses postgis-2.2
>
> select public.st_area(st_geomfromewkt('SRID=28992;POLYGON((100000
> 400000,100000 401000,101000 401000,101000 400000,100000 400000))'))
> -->1000000
> select public.area(st_geomfromewkt('SRID=28992;POLYGON((100000
> 400000,100000 401000,101000 401000,101000 400000,100000 400000))'))
> -->1000000
>
> Both work well now, so it seems that postgis.backend (or the GUC) is not a
> limiting factor anymore at all.
> Next: i wil try to reproduce this and share the code.
> (BTW is it OK to top post?)
>
>
>
> On Wed, Feb 24, 2016 at 5:01 PM, Willy-Bas Loos <willybas at gmail.com>
> wrote:
>
>> ah
>> reading into this: https://trac.osgeo.org/postgis/ticket/2382
>> hints me that this "GUC" thing remembers the postgis version somehow.
>> This especially has something to do with DDL.
>> So my loading legacy 2.2 set the GUC to postgis-2.2, solving the problem
>> for most functions.
>>
>> This isn't very reassuring though.
>> I'll look further into it and let you know.
>>
>> Cheers,
>>
>> WBL
>>
>>
> --
> Willy-Bas Loos
>
--
Willy-Bas Loos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20160224/0baff611/attachment.html>
More information about the postgis-users
mailing list