Re: plpython improvements - Mailing list pgsql-patches
From | Bruce Momjian |
---|---|
Subject | Re: plpython improvements |
Date | |
Msg-id | 200606162208.k5GM8tm22286@candle.pha.pa.us Whole thread Raw |
In response to | Re: plpython improvements (Hannu Krosing <hannu@tm.ee>) |
Responses |
Re: plpython improvements
|
List | pgsql-patches |
Added to TODO: o Allow PL/python to composite types and result sets once buggy assert-enabled versions of python can be detected http://archives.postgresql.org/pgsql-patches/2006-04/msg00087$ --------------------------------------------------------------------------- Hannu Krosing wrote: > ?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 > > > -- Bruce Momjian http://candle.pha.pa.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
pgsql-patches by date: