Tom Lane wrote:
>plperl's error handling is not completely broken, but it's close :-(
>Consider for example the following sequence on a machine with a
>relatively old Perl installation:
>
>
>
>
You just picked an easy way to trigger this. As you rightly observe,
there are others.
>We can deal with this in a localized fashion for plperl's elog()
>subroutine, by PG_CATCH'ing the longjmp and converting it into a Perl
>croak() call.
>
>
[...]
>What I think we ought to do is change both PL languages so that every
>SPI call is executed as a subtransaction. If the call elogs, we can
>clean up by aborting the subtransaction, and then we can report the
>error message as a Perl or Tcl error condition, which the function
>author can trap if he chooses. If he doesn't choose to, then the
>language interpreter will return an error condition to plperl.c or
>pltcl.c, and we can re-throw the error.
>
>
We can do both of these, no?
>This will slow down the PL SPI call operations in both languages, but
>AFAICS it's the only way to provide error handling semantics that aren't
>too broken for words.
>
>
>
>
Can you estimate the extent of the slowdown?
cheers
andrew