Tom>I think we still end up concluding that altering this behavior has more
Tom>downside than upside.
What is the downside?
Applications, drivers, and poolers already expect that commit might produce an error and terminate the transaction at the same time.
"The data is successfully committed to the database if and only if commit returns without error".
^^^ the above is way easier to reason about than "user must check multiple unrelated outcomes to tell if the changes are committed or not".