Обсуждение: 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 version of Python is included in RHEL or Fedora? what version of Python is included in MS Windows ?
What is the problem to provide both plpython2 and plpython3, or keep same (2 or 3) plpython available by default on both platforms?
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
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...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.
$ 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
Sad 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 theyprovide 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.
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.