On 05/27/2012 01:35 PM, Tom Lane wrote:
Adrian Klaver<adrian.kla...@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.kla...@gmail.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
