Robert>Now, of course, it's also true that if what the server does makes
Robert>users sad, maybe the server should do something different
The server makes users sad as it reports the same end result (=="commit failed") differently.
Sometimes the server produces ERROR, and sometimes the server produces "OK, the transaction was rolled back".
The users do expect that commit might fail, and they don't really expect that sometimes commit can be silently converted to a rollback.
Robert>BEGIN;
Robert>-- do stuff
Robert>COMMIT;
Robert>BEGIN;
Robert>-- do more stuff
Robert>COMMIT;
Robert>...and they run these scripts by piping them into psql. Now, if the
Robert>COMMIT leaves the session in a transaction state,
Noone suggested that "commit leaves the session in a transaction state".
Of course, every commit should terminate the transaction.
However, if a commit fails (for any reason), it should produce the relevant ERROR that explains what went wrong rather than silently doing a rollback.
