Robert Zenz <robert.zenz@sibvisions.com> writes:
> On 29.01.2018 15:11, Alban Hertroys wrote:
>> If you start a transaction and something goes wrong in the process,
>> the logical behaviour is to fail - the user will want to rollback to a
>> sane state, doing any more work is rather pointless because of that.
>> Allowing a commit at the end is dubious at best.
> One could argue that automatically "undoing all broken things" (read: reverting
> back to the state before the failing statement was executed) would be a feature
> worth having.
That behavior does exist, and so does documentation for it; you're just
looking in the wrong place.
Years ago (7.3 era, around 2002) we experimented with a server-side
GUC variable "AUTOCOMMIT", which switched from the implicit-commit-
if-you-don't-say-BEGIN behavior to implicitly-issue-BEGIN-so-you-
have-to-say-COMMIT-explicitly. That was an unmitigated disaster:
flipping the setting broke just about all client applications. After
spending many months trying to fix just the apps we ship with Postgres,
and getting pushback from users whose code broke with the alternate
setting, we gave up and removed the feature. Instead we set project
policy that if you want to modify transactional behavior you have to
do it on the client side, where it doesn't risk breaking other apps.
Institutional memory around here is very long, so any time proposals to
change the server or wire-protocol behavior in this area come up, they
get batted down.
What we do have though is client-side support for appropriate behaviors.
In psql, see the AUTOCOMMIT and ON_ERROR_ROLLBACK control variables.
Other interfaces such as JDBC have their own ideas about how this ought
to work.
regards, tom lane
