Dave Cramer <davecramer@postgres.rocks> writes:
> OK, here is a patch that actually doesn't leave the transaction in a failed
> state but emits the error and rolls back the transaction.
> This is far from complete as it fails a number of tests and does not cover
> all of the possible paths.
> But I'd like to know if this is strategy will be acceptable ?
I really don't think that changing the server's behavior here is going to
fly. The people who are unhappy that we changed it are going to vastly
outnumber the people who are happy. Even the people who are happy are not
going to find that their lives are improved all that much, because they'll
still have to deal with old servers with the old behavior for the
foreseeable future.
Even granting that a behavioral incompatibility is acceptable, I'm not
sure how a client is supposed to be sure that this "error" means that a
rollback happened, as opposed to real errors that prevented any state
change from occurring. (A trivial example of that is misspelling the
COMMIT command; which I'll grant is unlikely in practice. But there are
less-trivial examples involving internal server malfunctions.) The only
way to be sure you're out of the transaction is to check the transaction
state that's sent along with ReadyForQuery ... but if you need to do
that, it's not clear why we should change the server behavior at all.
I also don't think that this scales to the case of subtransaction
commit/rollback. That should surely act the same, but your patch doesn't
change it.
Lastly, introducing a new client-visible message level seems right out.
That's a very fundamental protocol break, independently of all else.
And if it's "not really an error", then how is this any more standards
compliant than before?
regards, tom lane
