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  (Sven <sven@spam.pri.ee>)
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:

Previous
From: Bruce Momjian
Date:
Subject: Re: [GENERAL] Omitting tablespace creation from pg_dumpall...
Next
From: Tom Lane
Date:
Subject: Re: table/index fillfactor control, try 2