Greg Stark wrote:
> Alvaro Herrera <alvherre@dcc.uchile.cl> 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 ROLLBACK
and 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