From: Tom Lane on
Peter Eisentraut <peter_e(a)gmx.net> writes:
> The problem is apparently that when CREATE LANGUAGE creates a language
> from a pg_pltemplate entry, it creates the proname from the tmplhandler
> name, and if it finds a fitting proname entry already, it used that one.
> So when you create plpython2 first and plpython3 second, the pg_language
> entries of the latter point to the pg_proc entries of the former.

> If you fix that up manually (create additional pg_proc entries and fix
> the pg_language entries to point there), it works better.

The fix ought to be to change the function nmes used by plpython3 ...

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Peter Eisentraut on
On fre, 2010-06-25 at 10:17 -0400, Tom Lane wrote:
> Peter Eisentraut <peter_e(a)gmx.net> writes:
> > The problem is apparently that when CREATE LANGUAGE creates a language
> > from a pg_pltemplate entry, it creates the proname from the tmplhandler
> > name, and if it finds a fitting proname entry already, it used that one.
> > So when you create plpython2 first and plpython3 second, the pg_language
> > entries of the latter point to the pg_proc entries of the former.
>
> > If you fix that up manually (create additional pg_proc entries and fix
> > the pg_language entries to point there), it works better.
>
> The fix ought to be to change the function nmes used by plpython3 ...

Right. What shall we do about the catversion?
From: Tom Lane on
Peter Eisentraut <peter_e(a)gmx.net> writes:
> On fre, 2010-06-25 at 10:17 -0400, Tom Lane wrote:
>> The fix ought to be to change the function nmes used by plpython3 ...

> Right. What shall we do about the catversion?

You could argue it either way. The number of beta testers with
plpython3 installations is probably very small, so I'm kinda leaning to
just changing the code without a catversion bump. OTOH, if we want to
encourage testing of pg_upgrade ...

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Josh Berkus on

> You could argue it either way. The number of beta testers with
> plpython3 installations is probably very small, so I'm kinda leaning to
> just changing the code without a catversion bump. OTOH, if we want to
> encourage testing of pg_upgrade ...

FWIW, the last bump has led to a lot of testing of pgupgrade.

--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Andres Freund on
On Wednesday 23 June 2010 16:30:54 Tom Lane wrote:
> Robert Haas <robertmhaas(a)gmail.com> writes:
> > I can reproduce this, here. The problem seems to be that plpython
> > only build either plpython2.so or plython3.so, but both languages
> > expect a call handler called plython_call_handler. So once we load
> > the shared library for one language, the other language just grabs the
> > same call handler.
>
> We had better fix that --- I can definitely foresee installations
> wanting to use both plpython2 and plpython3. This'd require a change in
> the default contents of pg_pltemplate, though. Does it seem important
> enough to bump catversion for?
Has anybody actually researched if it is safe to run python2 and python3 in
the same address space? I wouldnt be surprised at all if that where
problematic.

Andres

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers