Alvaro Herrera <[EMAIL PROTECTED]> writes:
If we change the syntax, say by using SUBCOMMIT/SUBABORT for subtransactions, then using a simple ABORT would abort the whole transaction tree.
This seems like a non-starter to me. That would make it impossible to write SQL generic code that could be used from within a transaction or as a top-level transaction.
I think it's vital that any use of the existing (pre-7.5) syntax for COMMIT/ROLLBACK/ABORT results in all transaction state being cleared, for compatibility with older applications.
Consider JDBC's Connection.commit() and Connection.rollback() methods. They need to deal in terms of the top-level transaction: connection pools and similar are going to issue rollback() and expect all transaction state to be cleaned up, regardless of what the pool's client has done with the connection. The connection pool code is unlikely to be aware of subtransactions -- JDBC has no equivalent concept (it has savepoints, but that's it).
If ROLLBACK always affects the top-level transaction, the JDBC driver's job is simple: Connection.rollback() always issues ROLLBACK. If you need some other syntax to get a top-level rollback, the driver's job gets messier:
if we have at least a 7.5 server:
issue ROLLBACK ALL
else:
issue ROLLBACKand older drivers which always issue ROLLBACK are going to break in nonobvious ways if their applications start using subtransactions.
This seems like a gratuitous incompatibility to introduce. I'd expect other clients that aren't aware of subtransactions to stumble on this too.
-O
---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend
