Re: plpython improvements - Mailing list pgsql-patches

From Sven Suursoho
Subject Re: plpython improvements
Date
Msg-id op.s8t3cgfuplgmb3@localhost
Whole thread Raw
In response to Re: plpython improvements  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: plpython improvements  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-patches
Sun, 30 Apr 2006 20:48:48 +0300, Bruce Momjian <pgman@candle.pha.pa.us>:

>> 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 guess there should be warning somewhere as Hannu said but didn't
>> know
>> >> where to put it.
>> >
>> > 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 normal python installations do not cause problem, only
>> debugging versions do.
>>
>> Anyway, if you think that this doesn't count as an argument, there is
>> nothing that we can do from PG-side except drop returning SETOF as
>> iterator/generator and only allow return SETOF as list.
>
> Can't we detect a debug build and disable the feature?

Yes, we can, but newer python versions are already fixed.

So, what about this in configure:
if --with-python && test_iterator_app_crashes
   # errcode(FEATURE_NOT_SUPPORTED), errmsg(patch your python)
   disable_iterator_feature
fi

In this way we disable feature only if it is absolutely neccessary and
will give developer enough information how to fix it.


--
Sven Suursoho

pgsql-patches by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: plpython improvements
Next
From: Tom Lane
Date:
Subject: Re: plpython improvements