"Scott Marlowe" <smarlowe@qwest.net> writes:
> Why not rollback all or commit all?
>
> I really really don't like subbegin and subcommit. I get the feeling
> they'll cause more problems we haven't foreseen yet, but I can't put my
> finger on it.
Well I've already pointed out one problem. It makes it impossible to write
generic code or reuse existing code and embed it within a transaction. Code
meant to be a nested transaction within a larger transaction becomes
non-interchangeable with code meant to be run on its own.
I also have a different issue. The behaviour I'm expecting with most drivers
will be to start a transaction immediately, and run every query within a
subtransaction. This is what we've discussed previously with psql, but for the
same reasons previously discussed I expect drivers to adopt the same approach,
at least when not in autocommit mode. The goal would be to allow the
application to control what happens when a given query returns an error and
not force the application to roll the entire transaction back.
This means the user can't use "BEGIN" or "END" at all himself. Since the
driver would already have initiated a transaction itself. The *only*
user-visible commands would become these awkward (and frankly, silly-sounding)
"SUBBEGIN" and "SUBEND".
I have an related question though. Will there be a out of band protocol method
for controlling transaction status? If the v3 protocol allows the transaction
status to be manipulated in binary messages that don't interact with user
queries then a driver would still be able to reliably start and end
transactions and nested transactions. If that were the case I guess I wouldn't
care since a driver could then implement an external API that hid the
irregularity of SUBfoo from the user and provided a consistent ->begin()
->end(). The driver could emulate this by inserting SUBfoo commands into the
stream but then it would risk being subverted by user commands.
--
greg
