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:James William Pye <[EMAIL PROTECTED]> 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.
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
---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
