Re: plpython improvements - Mailing list pgsql-patches

From Hannu Krosing
Subject Re: plpython improvements
Date
Msg-id 1146837329.3830.17.camel@localhost.localdomain
Whole thread Raw
In response to Re: plpython improvements  ("Sven Suursoho" <sven@spam.pri.ee>)
Responses Re: plpython improvements
Re: plpython improvements
List pgsql-patches
Ühel kenal päeval, N, 2006-05-04 kell 18:21, kirjutas Sven Suursoho:
> Hi,
>
>
> Sun, 30 Apr 2006 19:14:28 +0300, Tom Lane <tgl@sss.pgh.pa.us>:
>
> > "Sven Suursoho" <sven@spam.pri.ee> writes:
> >> Unfortunately, there is still one problem when using unpatched python,
> >> caused by too aggressive assert.
> >> http://mail.python.org/pipermail/python-checkins/2005-August/046571.html.
> >
> > I don't think we are going to be able to accept a patch that causes the
> > server to crash when using any but a bleeding-edge copy of Python.

Actually not bleeding-edge, but just version 2.4.x as distributed in
Fedora Core (and possibly in RHAS), which have assert() enabled in
python.so.

The assert there is buggy (bug
http://sourceforge.net/tracker/index.php?func=detail&aid=1257960&group_id=5470&atid=105470)

> Did complete rewrite for SETOF functions: now accepts any python object
> for which iter(object) returns iterable object. In this way we don't have
> to deal with specific containers but can use unified python iterator API.
> It means that plpython is future-proof -- whenever python introduces new
> container, stored procedures already can use those without recompiling
> language handler.
>
> Also integrated with regression tests and updated existing tests to use
> named parameters.
>
> When using python interpreter with asserts enabled, generators still
> crash. But I don't think that we should drop this feature because of that.
> Reasons:
> 1) this is someone else's bug, we are using documented API correctly
> 2) it doesn't concern majority of users because probably there is no
> asserts in production packages (tested with gentoo, ubuntu, suse). This is
> true even for older python versions that are not patched.

From reading the bug, it seems that older versions of python also don't
have this bug, only 2.4.

> And after all, we can document using sets, lists, tuples, iterators etc
> and explicitly state that returning generator is undefined.

I think that a less confusing way of saying it would be :

 "Generators crash if python version used is 2.4.x and it is compiled
 with asserts.

 Currently only known linux distributions to distibute such python.so
 files are Fedora and possibly other RedHat distributions, while
 Gentoo, Ubuntu and Suse are OK.

 If you need to use generators on such a platform, compile your own
 python from source and make sure that configure uses your version."


I think the patch should be commited so we can collect data about where
else the buggy version of python exists.

And if some buildfarm machines start crashing, python should be fixed
there.

----------------
Hannu




pgsql-patches by date:

Previous
From: Martijn van Oosterhout
Date:
Subject: Re: Have configure complain about unknown options
Next
From: Robert Lor
Date:
Subject: Re: [BUGS] BUG #2401: spinlocks not available on amd64