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
