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 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?
> Yeah, I think so.  As for using both plpython2 and plpython3, it looks
> to me like right now you can only use one or the other.  I think if
> you somehow manage to install both, you're really just getting the
> same one twice (I have not tested this, however).

So, what's the right thing to do here?  Should we just fix it so that
creating the second language always fails, or should we try to make it
possible for both of them to coexist (which is probably a lot more

Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to