Re: Packaging of plpython

On Sat, Sep 8, 2012 at 12:05 AM, John R Pierce <pierce(at)hogranch(dot)com> wrote:

> On 09/07/12 1:57 PM, Gražvydas Valeika wrote:
>
>>
>> I don't use RHEL, I use Scientific Linux clone of it. And
>> yum.postgresql.org <http://yum.postgresql.org/> repository packages. It
>> contains plpyton2. In Fedora 16 - fedora repostitories, plpython2. In
>> Windows - Enterprise DB 32 bit installer, contains plpython3.dll which uses
>> Python 3. No sign of plpython2. Same with 64 bit binaries zip file (I don't
>> have installed 64 bit PG on Windows). In windows, PG contains plpython3u
>> description files in share/extension directory, but doesn't have
>> plpython2.dll file required by these module definitions.
>>
>
> plpython is dependent on python. and EL6 ships with
>
> python.x86_64 2.6.6-29.el6 @base
>
> so if yum.postgresql.org was built with python3 support, it would have to
> supply an alternate version of the python runtime, which would have to be
> installed somewhere OTHER than the default python location or it would
> break various RHEL built in utilities that depend on Python, such as... YUM
> itself.
>
>
>
> OK. It seemed to me, that plpython2 and plpython3 were introduced exactly
for this reason.

Postgres documentation (
http://www.postgresql.org/docs/9.1/static/plpython-python23.html) states:

It is not allowed to use PL/Python based on Python 2 and PL/Python based on
Python 3 in the same session, because the symbols in the dynamic modules
would clash, which could result in crashes of the PostgreSQL server
process. There is a check that prevents mixing Python major versions in a
session, which will abort the session if a mismatch is detected. It is
possible, however, to use both PL/Python variants in the same database,
from separate sessions.