On Dec 3, 2004, at 2:04 PM, Jan Wieck wrote:
[snip]
>
> 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.
>
> 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.
>
The JDBC interface exposes the savepoint interface, via setSavepoint(),
releaseSavepoint(), and rollback(Savepoint sp) methods on the
Connection, and Thomas's design of PL/Java offers the SPI via mapping
it onto JDBC. Would client-side JDBC also suffer from the same
potential issue of 'commit a savepoint made by a sub-function'? Or is
this something SPI-specific? Or, finally, is this an issue of
interacting with other PL languages who won't expose savepoint-ish
functionality?
IMO, if it smells like JDBC, it oughta smell as close to 100% like
JDBC, allowing folks to possibly relocate some of their code to run
inside PG. Ugly savepoint handling and all.
----
James Robinson
Socialserve.com