James William Pye <flaw@rhid.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.
regards, tom lane
