Re: [HACKERS] testing plpython3u on 9.0beta2

2010-06-28 Thread Robert Haas
On Fri, Jun 25, 2010 at 2:49 PM, Peter Eisentraut pete...@gmx.net wrote: On fre, 2010-06-25 at 10:17 -0400, Tom Lane wrote: Peter Eisentraut pete...@gmx.net writes: The problem is apparently that when CREATE LANGUAGE creates a language from a pg_pltemplate entry, it creates the proname from

Re: [HACKERS] testing plpython3u on 9.0beta2

2010-06-28 Thread Bruce Momjian
Josh Berkus wrote: 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

Re: [HACKERS] testing plpython3u on 9.0beta2

2010-06-28 Thread Tom Lane
Bruce Momjian br...@momjian.us writes: Josh Berkus wrote: 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

Re: [HACKERS] testing plpython3u on 9.0beta2

2010-06-28 Thread Bruce Momjian
Tom Lane wrote: Bruce Momjian br...@momjian.us writes: Josh Berkus wrote: 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

Re: [HACKERS] testing plpython3u on 9.0beta2

2010-06-28 Thread Peter Eisentraut
On fre, 2010-06-25 at 18:57 -0400, Peter Eisentraut wrote: On fre, 2010-06-25 at 23:44 +0200, Andres Freund wrote: Has anybody actually researched if it is safe to run python2 and python3 in the same address space? You can't run plpython2 and plpython3 in the same session, because the

Re: [HACKERS] testing plpython3u on 9.0beta2

2010-06-28 Thread Tom Lane
Peter Eisentraut pete...@gmx.net writes: Why are we using RTLD_GLOBAL? Some guy named Eisentraut wanted it for plpython: http://archives.postgresql.org/pgsql-hackers/2001-05/msg00563.php http://archives.postgresql.org/pgsql-committers/2001-05/msg00283.php Possibly that no longer applies,

Re: [HACKERS] testing plpython3u on 9.0beta2

2010-06-25 Thread Tom Lane
Peter Eisentraut pete...@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

Re: [HACKERS] testing plpython3u on 9.0beta2

2010-06-25 Thread Peter Eisentraut
On fre, 2010-06-25 at 10:17 -0400, Tom Lane wrote: Peter Eisentraut pete...@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,

Re: [HACKERS] testing plpython3u on 9.0beta2

2010-06-25 Thread Tom Lane
Peter Eisentraut pete...@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

Re: [HACKERS] testing plpython3u on 9.0beta2

2010-06-25 Thread Josh Berkus
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

Re: [HACKERS] testing plpython3u on 9.0beta2

2010-06-25 Thread Andres Freund
On Wednesday 23 June 2010 16:30:54 Tom Lane wrote: Robert Haas robertmh...@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

Re: [HACKERS] testing plpython3u on 9.0beta2

2010-06-25 Thread Peter Eisentraut
On fre, 2010-06-25 at 23:44 +0200, Andres Freund wrote: Has anybody actually researched if it is safe to run python2 and python3 in the same address space? You can't run plpython2 and plpython3 in the same session, because the libraries are loaded with dlopen(RTLD_GLOBAL) (with RTLD_LOCAL it

Re: [HACKERS] testing plpython3u on 9.0beta2

2010-06-24 Thread Robert Haas
On Wed, Jun 23, 2010 at 10:49 AM, Robert Haas robertmh...@gmail.com wrote: On Wed, Jun 23, 2010 at 10:30 AM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: I can reproduce this, here.  The problem seems to be that plpython only build either plpython2.so or

Re: [HACKERS] testing plpython3u on 9.0beta2

2010-06-24 Thread Peter Eisentraut
On ons, 2010-06-23 at 07:17 -0400, Robert Haas wrote: 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,

Re: [HACKERS] testing plpython3u on 9.0beta2

2010-06-23 Thread Robert Haas
On Tue, Jun 22, 2010 at 10:41 PM, Chris rfu...@gmail.com wrote: I received two errors (described below) in installing 9.0beta2 on Kubuntu 10.04 , RhodiumToad on IRC recommended I post them here. I did not have a 2.x or 3.x python dev installed, but I was really only interested in python3 via

Re: [HACKERS] testing plpython3u on 9.0beta2

2010-06-23 Thread Tom Lane
Robert Haas robertmh...@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

Re: [HACKERS] testing plpython3u on 9.0beta2

2010-06-23 Thread Robert Haas
On Wed, Jun 23, 2010 at 10:30 AM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@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.