Thread: Packaging of plpython

Packaging of plpython

From
Gražvydas Valeika
Date:
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.

Re: Packaging of plpython

From
"Joshua D. Drake"
Date:
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


Re: Packaging of plpython

From
John R Pierce
Date:
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




Re: Packaging of plpython

From
Gražvydas Valeika
Date:


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.

Re: Packaging of plpython

From
John R Pierce
Date:
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




Re: Packaging of plpython

From
John R Pierce
Date:
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



Re: Packaging of plpython

From
Gražvydas Valeika
Date:


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.

Re: Packaging of plpython

From
John R Pierce
Date:
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




Re: Packaging of plpython

From
Gražvydas Valeika
Date:

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


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.


Re: Packaging of plpython

From
Peter Eisentraut
Date:
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.



Re: Packaging of plpython

From
Gražvydas Valeika
Date:
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. 

Personally, I think the Windows packagers made a mistake by providing
Python 3 only at this point.

+1 

Re: Packaging of plpython

From
John R Pierce
Date:
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



Re: Packaging of plpython

From
Gražvydas Valeika
Date:

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.