[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