Re: Error handling in plperl and pltcl
От | Andrew Dunstan |
---|---|
Тема | Re: Error handling in plperl and pltcl |
Дата | |
Msg-id | 419E8532.8000905@dunslane.net обсуждение исходный текст |
Ответ на | Error handling in plperl and pltcl (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Error handling in plperl and pltcl
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: