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: