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