Packaging of plpython
Hi all,
somebody please explain what is packaging policy of plpython. Now I see
plpython2u packaged in Fedora and RHEL repositories and plpython3u in
Windows installer by EnterpriseDB.
Why there is such difference and what is advertised way to keep DB servers
in Linux and Windows plpython compatible?
Difference in supported plpython versions for Linux/Windows adds
unnecessary difficulty.
Till now all I managed to google is advice to build required modules by
ourself.
What is the problem to provide both plpython2 and plpython3, or keep same
(2 or 3) plpython available by default on both platforms?
It seems to me, that this policy remains unchanged for 9.2.
Regards,
G.
On 09/07/2012 12:41 PM, Gražvydas Valeika wrote:
Hi all,
somebody please explain what is packaging policy of plpython. Now I see
plpython2u packaged in Fedora and RHEL repositories and plpython3u in
Windows installer by EnterpriseDB.Why there is such difference and what is advertised way to keep DB
servers in Linux and Windows plpython compatible?
Because you are using non .Org packages. It is up to the distribution
whether linux or Windows to determine what is packaged, not .Org.
Joshua D. Drake
--
Command Prompt, Inc. - http://www.commandprompt.com/
PostgreSQL Support, Training, Professional Services and Development
High Availability, Oracle Conversion, Postgres-XC
@cmdpromptinc - 509-416-6579
On 09/07/12 12:41 PM, Gražvydas Valeika wrote:
What is the problem to provide both plpython2 and plpython3, or keep
same (2 or 3) plpython available by default on both platforms?
what version of Python is included in RHEL or Fedora? what version of
Python is included in MS Windows ?
--
john r pierce N 37, W 122
santa cruz ca mid-left coast
On Fri, Sep 7, 2012 at 11:27 PM, John R Pierce <pierce@hogranch.com> wrote:
On 09/07/12 12:41 PM, Gražvydas Valeika wrote:
What is the problem to provide both plpython2 and plpython3, or keep same
(2 or 3) plpython available by default on both platforms?what version of Python is included in RHEL or Fedora? what version of
Python is included in MS Windows ?sorry, missed the list.
To Jushua:
Scientific Linux 64 bit which uses repository pointing to:
http://yum.postgresql.org/9.1/redhat/rhel-$releasever-$basearch
and has installed postgresql91-plpython-9.1.5-3PGDG.rhel6.x86_64
in
/usr/pgsql-9.1/share/extension
directory contains plpython2u and plpythonu, but no plpython3u.
I don't use RHEL, I use Scientific Linux clone of it. And
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.
It seems that linux packages (postgresql.org and distribution) are biased
to python2, EneterpriseDB windows installer to python3.
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.
--
john r pierce N 37, W 122
santa cruz ca mid-left coast
On 09/07/12 2:05 PM, John R Pierce wrote:
plpython is dependent on python.
minor correction, its dependent on python-libs, but the rest still applies.
--
john r pierce N 37, W 122
santa cruz ca mid-left coast
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.
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.
On 09/07/12 2:26 PM, Gražvydas Valeika wrote:
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.
yes, but again, plpython3 would depend on having python-libs for python
3.x, which EL5/6 do not provide. the plpython provided by
yum.postgresql.org has dependency on...
$ yum deplist postgresql91-plpython
postgresql91-plpython.x86_64 9.1.5-3PGDG.rhel6
.....
dependency: libpython2.6.so.1.0()(64bit)
provider: python-libs.x86_64 2.6.6-29.el6_2.2
--
john r pierce N 37, W 122
santa cruz ca mid-left coast
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<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.yes, but again, plpython3 would depend on having python-libs for python
3.x, which EL5/6 do not provide. the plpython provided by
yum.postgresql.org has dependency on...$ yum deplist postgresql91-plpython
postgresql91-plpython.x86_64 9.1.5-3PGDG.rhel6
.....
dependency: libpython2.6.so.1.0()(64bit)
provider: python-libs.x86_64 2.6.6-29.el6_2.2Sad but you are right. My impression of possibility to use python3 was
because there are packages for python3 for Fedora. EL prevents python3
everywhere compatible environment.
So, there is hope, that EnterpriseDB will provide python2.dll for 9.2.
For 9.1 I found it posted somewhere in support forum. This time I can be
not so lucky.
On Fri, 2012-09-07 at 22:41 +0300, Gražvydas Valeika wrote:
What is the problem to provide both plpython2 and plpython3, or keep
same (2 or 3) plpython available by default on both platforms?
It is the decision of the respective packagers which version they
provide and how much effort they want to put in. If you have issues
with their decisions, you could try to submit a bug report to their
respective bug trackers.
Btw., Debian and Ubuntu provide PL/Python for Python 2 and 3, so it's
possible. And it happened because someone submitted a bug report, and
someone put in the effort. ;-)
Personally, I think the Windows packagers made a mistake by providing
Python 3 only at this point.
It is the decision of the respective packagers which version they
provide and how much effort they want to put in. If you have issues
with their decisions, you could try to submit a bug report to their
respective bug trackers.Btw., Debian and Ubuntu provide PL/Python for Python 2 and 3, so it's
possible. And it happened because someone submitted a bug report, and
someone put in the effort. ;-)
I guess this mailing list topic has got enough EDB people eyeballs, but is
not touching enough.
I suspect time will be spent more productive creating windows build
environment and building required thing by oneself.
Show quoted text
Personally, I think the Windows packagers made a mistake by providing
Python 3 only at this point.+1
On 09/08/12 9:26 AM, Peter Eisentraut wrote:
Personally, I think the Windows packagers made a mistake by providing
Python 3 only at this point.
does the windows package include its own self sufficient python runtime,
or does it rely on a specific 3rd party python being installed ? if
the latter, is python 2.x available or just 3.x ?
--
john r pierce N 37, W 122
santa cruz ca mid-left coast
does the windows package include its own self sufficient python runtime,
or does it rely on a specific 3rd party python being installed ? if the
latter, is python 2.x available or just 3.x ?
As I understand plpython on windows is only adapter to ActiveState Python
2 or 3. EDB installer doesn't include in distribution package Python
runtime.
Windows doesn't include preinstalled python of any kind. While installing
plpython you must to download and preinstall ActiveState Python version 3
(because EDB installer doesn't contain Python 2 adapter dll).
Windows installer has another problem. It requires specific version of
ActiveState Python, but ActiveState allows to download those versions of
Python only limited time. After it releases new version old version becomes
available only to paying ActiveState customers effectively prohibiting
plpython to Postgres Windows customers who discover their need of plpython
too late.