Re: plpython improvements

Поиск
Список
Период
Сортировка
От Hannu Krosing
Тема Re: plpython improvements
Дата
Msg-id 1146837329.3830.17.camel@localhost.localdomain
обсуждение исходный текст
Ответ на Re: plpython improvements  ("Sven Suursoho" <sven@spam.pri.ee>)
Ответы Re: plpython improvements
Re: plpython improvements
Список 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 по дате отправления:

Предыдущее
От: Martijn van Oosterhout
Дата:
Сообщение: Re: Have configure complain about unknown options
Следующее
От: Robert Lor
Дата:
Сообщение: Re: [BUGS] BUG #2401: spinlocks not available on amd64