Re: Error handling in plperl and pltcl

Tom Lane wrote:
> James William Pye <flaw(at)rhid(dot)com> writes:
>
>>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.
>
>
> You're right. You can *not* expose those as user-callable operations in
> a PL language. Consider for example what will happen if the user tries
> to roll back to a savepoint that was established outside your function
> call, or tries to exit the function while still inside a local
> savepoint. You have to enforce strict nesting of functions and
> subtransactions; therefore it's a lot easier to present an API that
> looks like an exception-block construct (per plpgsql), or that just
> hides the whole deal in the SPI calling interface (as I'm proposing for
> plperl/pltcl).
>
> There's been some discussion of creating a "stored procedure" language
> that would execute outside the database engine, but still on the server
> side of the network connection. In that sort of context it would be
> reasonable to let the user do SAVEPOINT/ROLLBACK (or any other SQL
> command). But our existing PLs most definitely execute inside the
> engine, and therefore they can't expose facilities that imply arbitrary
> changes in the subtransaction state stack.
>
I'm planning to add subtransactions too, but my approach will be to use
the savepoint functionality already present in the java.sql.Connection
interface. Perhaps the plpy implementation could do something similar.
This is what I'm planning to implement:

In Java, safepoints are identified by an interface rather then just by a
name. I will (invisibly) include both the name of the safepoint and the
call level in my implementation of that interface. I will also have a
nested "call context" where I manage safepoints created by the executing
function. All of this will be completely hidden from the function
developer. This will make it possible to enforce the following rules:

1. A Safepoint lifecycle must be confined to a function call.
2. Safepoints must be rolled back or released by the same function that
sets them.

Failure to comply with those rules will result in an exception (elog
ERROR) that will be propagated all the way up.

Would you consider this as safe?

Regards,
Thomas Hallgren