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

On 05/27/2012 01:35 PM, Tom Lane wrote:
> Adrian Klaver<adrian.klaver@gmail.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.klaver@gmail.com