Re: BUG #6666: pg_upgrade 9.2beta1 plpython/plpython2

On 05/27/2012 01:35 PM, Tom Lane wrote:
> Adrian Klaver<adrian(dot)klaver(at)gmail(dot)com> writes:
>> After reading the above thread here is what the queries mentioned return:
>
>> production=# SELECT nspname,proname,probin FROM pg_proc,pg_namespace
>> WHERE probin LIKE '%python%' and pg_proc.pronamespace=pg_namespace.oid;
>
>> nspname | proname | probin
>> ------------+-------------------------+------------------
>> pg_catalog | plpython_call_handler | $libdir/plpython
>> pg_catalog | plpython_inline_handler | $libdir/plpython
>> public | plpython_call_handler | $libdir/plpython
>> (3 rows)
>
> I think what you need to do is drop the one in public, ie
> drop function public.plpython_call_handler();
> The other two are what the language is actually using nowadays.

I will give that a try.

Though knowing what the problem is I wonder if another solution is to
make the plpythonu lib layout follow the description of the 2/3 split
detailed here:

http://www.postgresql.org/docs/9.2/static/plpython-python23.html

In particular:
"The language named plpythonu implements PL/Python based on the default
Python language variant, which is currently Python 2"

In other words automatically create a symlink:

plpython.so -> plpython2.so*

>
> Hopefully pg_upgrade will then cope with upgrading them ...
>
> regards, tom lane

--
Adrian Klaver
adrian(dot)klaver(at)gmail(dot)com