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
