Has this been addressed?
---------------------------------------------------------------------------
> Bradley McLean <brad@bradm.net> writes:
> > In Option (C), I set the global "InError" flag to false, and then
> > return NULL, causing all of the error messages to come out and
> > plpython to clean up gracefully, no backend crash. However, this
> > seems to be an unprecedented approach, and I could be missing
> > something big.
>
> Yes, as in "it's totally unsafe". Suppressing an elog(ERROR) is
> a *big* no-no at present, because way too much stuff relies on
> post-abort cleanup to clean up whatever problem is being reported.
> You cannot allow the transaction to continue after the error, and
> you most certainly mustn't cavalierly reset the error handling state.
>
> The only things you should be doing with longjmp trapping are
> (a) doing any cleanup that Python itself has to have before you
> re-propagate the longjmp, or
> (b) issuing elog(NOTICE) to help identify the error location
> before you re-propagate the longjmp.
>
> plpgsql contains an example of doing (b).
>
> Not propagating the longjmp, which is what the code seems to be doing
> at present, is not acceptable. I had not looked at this code closely,
> but as-is it is a huge reliability hazard. I will insist on removing
> plpython from 7.2 entirely if this can't be fixed before release.
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly
>
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026