On Sat, Sep 8, 2012 at 12:05 AM, John R Pierce <pie...@hogranch.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.
