Thanks, I assumed something like that.
I can very quickly provide at implementation that meets
these criteria (It's my option "b"), but it may be
less informative in terms of messages.
I'll have a look to see what I can do to supplement
the messages.
I also need to check if there's a memory leak after I
fix it.
I was aware of the example in plpgsql.
-Brad
* Tom Lane (tgl@sss.pgh.pa.us) [011113 17:08]:
>
> 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