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
---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings
