Jan Wieck wrote:
"as you now suggest"? I don't remember suggesting that. I concluded from your statements that _you_ are against changing Tcl's catch but instead want the savepoint functionality exposed to plain Tcl. So _you_ are against _my_ suggestion because these two are mutually exclusive.
I probably misinterpreted what you wrote in your last post where you wrote "What you mean with "normal" savepoint handling in fact means that we don't change catch at all but just expose the savepoint feature on the Tcl level.". I thought you ment that you actually would expose the savepoints in Tcl.
You want the capabilities of C or Assembler (including all possible failures that lead to corruptions) in a trusted procedural language. I call that far from "ideal".
No I don't. I'm not sure how you came to that conclusion. I'm all for a good, 100% safe design and clean interfaces.
The point we where coming from was Tom's proposal to wrap each and every single SPI call into its own subtransaction for semantic reasons. My proposal was an improvement to that with respect to performance and IMHO also better matching the semantics.
As I said earlier, I think you proposal is great as a stop-gap solution for 8.0. But when full savepoint support is enabled using SPI calls, the implementation should change IMHO.
Your suggestion to expose a plain savepoint interface to the programmer leads directly to the possiblity to commit a savepoint made by a sub-function in the caller and vice versa - which if I understood Tom correctly is what we need to avoid.
That particluar scenario is very easy to prevent. You just maintain a savepoint structure that keeps track of function call level. The lifecycle of a savepoint cannot exceed the lifecycle of the invocation where it was created and it cannot be released or rolled back at a higher level. An attemt to do so would yield an unrecoverable error.
Regards, Thomas Hallgren
---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
