Re: Error handling in plperl and pltcl

On Fri, 2004-11-19 at 16:58 -0500, Tom Lane wrote:
> 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.

I do this already in my plpy, save the subtransaction handling
"feature".
In plpy, all Postgres ERRORs are caught and transformed into Python
exceptions, then when the interpreter exits with a Python exception, it
is transformed back into a Postgres ERROR and raised. I even created a
class of Python exceptions for Postgres ERRORs(e.g. raise
Postgres.ERROR('msg', code=someErrCode, hint='foo')). (And more specific
classes as well, putting errcodes to good use.)

I plan(well, already working on it) to create Python interfaces to
Postgres transaction facilities so that the author can start, rollback,
and commit subxacts as needed for use/cleanup. Of course, I feel that
this is the best way to go AFA subxacts are concerned; leaving the
details to the author.

I have been playing with RollbackToSavepoint and ReleaseSavepoint, but
per Neil's comments on IRC and the fact that I have to annoyingly
construct a List containing the savepoint name. I get the feeling that I
am not meant to use them. If they are provided for possible use,
shouldn't they take a string instead of a List? (Is a List used here to
discourage use?)

--
Regards,
James William Pye