<div dir="ltr"><div>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<br>postgresql-9.4.6-1.pgdg14.04+1 will not install any of the old legacy functions, stating <br>  ERROR:  attempt to redefine parameter "postgis.backend"<br>postgresql-9.4.6-1.pgdg70+1 will only state <br>  WARNING:  'postgis.backend' is already set and cannot be changed until you reconnect<br></div><div>and then create all the (probably bad) functions.<br><br></div><div>Here's how to reproduce:<br></div><div><ol><li>log into a server that runs postgresql-9.4 and postgis 2.1 (but not postgis 2.2)<br></li><li>create a database</li><li>create extension postgis</li><li>\i .../legacy.sql</li><li>make a dump of that</li><li>restore it on a server that runs postgresql-9.4.6-1.pgdg70+1 and postgis 2.2</li></ol><p>I can provide the dump file of step 5 if anyone wants it.<br></p></div><div><br></div><div>BUT i cannot reproduce the problems that i assume are caused by this (the subject of this thread).<br></div><div>I only get a warning when using the function that refers to the old lib (area instead of st_area)<br><br></div><div>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.<br></div><div>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.<br></div><div>So if anyone has a clue please help.<br></div><div><br></div><div>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 <a href="http://postgis.net/docs/manual-2.2/postgis_backend.html">this</a>.<br></div><div><br></div><div><br></div><div>leg=# select public.st_area(st_geomfromewkt('SRID=28992;POLYGON((100000 400000,100000 401000,101000 401000,101000 400000,100000 400000))'))<br>;<br> st_area <br>---------<br> 1000000<br>(1 row)<br><br>leg=# select public.area(st_geomfromewkt('SRID=28992;POLYGON((100000 400000,100000 401000,101000 401000,101000 400000,100000 400000))'))<br>;<br><b>WARNING</b>:  'postgis.backend' is already set and cannot be changed until you reconnect<br>  area   <br>---------<br> 1000000<br>(1 row)<br><br>leg=# SELECT distinct n.nspname||'.'||p.proname as function, p.probin --, pg_get_function_identity_arguments(p.oid) AS params<br>FROM   pg_proc p<br>JOIN   pg_namespace n ON n.oid = p.pronamespace<br>WHERE  p.proname in ('area', 'st_area');<br>    function     |       probin        <br>-----------------+---------------------<br> public.area     | $libdir/postgis-2.1<br> pg_catalog.area | <br> public.st_area  | <br> public.st_area  | $libdir/postgis-2.2<br>(4 rows)<br><br><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 24, 2016 at 5:41 PM, Willy-Bas Loos <span dir="ltr"><<a href="mailto:willybas@gmail.com" target="_blank">willybas@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div>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.<br></div>area(geometry) uses postgis-2.1<br></div>and st_area(geometry) uses postgis-2.2<br></div><br>select public.st_area(st_geomfromewkt('SRID=28992;POLYGON((100000 400000,100000 401000,101000 401000,101000 400000,100000 400000))'))<br>-->1000000<br>select public.area(st_geomfromewkt('SRID=28992;POLYGON((100000 400000,100000 401000,101000 401000,101000 400000,100000 400000))'))<br>-->1000000<br><br>Both work well now, so it seems that postgis.backend (or the GUC) is not a limiting factor anymore at all. <br></div>Next: i wil try to reproduce this and share the code.<br></div>(BTW is it OK to top post?)<br><div><div><br><br></div><div class="gmail_extra"><span class=""><br><div class="gmail_quote">On Wed, Feb 24, 2016 at 5:01 PM, Willy-Bas Loos <span dir="ltr"><<a href="mailto:willybas@gmail.com" target="_blank">willybas@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div>ah<br></div>reading into this: <a href="https://trac.osgeo.org/postgis/ticket/2382" target="_blank">https://trac.osgeo.org/postgis/ticket/2382</a><br></div>hints me that this "GUC" thing remembers the postgis version somehow. This especially has something to do with DDL.<br></div><div>So my loading legacy 2.2 set the GUC to postgis-2.2, solving the problem for most functions.<br><br></div><div>This isn't very reassuring though.<br></div><div>I'll look further into it and let you know.<br><br></div><div>Cheers,<br><br></div><div>WBL<br></div></div><br clear="all"></blockquote></div><br></span><span class="HOEnZb"><font color="#888888">-- <br><div><div dir="ltr">Willy-Bas Loos<br></div></div>
</font></span></div></div></div>
</blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature"><div dir="ltr">Willy-Bas Loos<br></div></div>
</div>