I would like to bring up again the topic of statement-level rollback.
This was discussed in some depth at [1]. This patch is not based on
Tsunakawa-san's patch submitted in that thread; although I started from
it, I eventually removed almost everything and replaced with a
completely different implementation.
Patch 0001 here attached introduces the new setting and behavior with a
few applicability restrictions I outlined in [2], on safety grounds.
However, that wasn't exactly met with the standing ovation that I was
expecting[3], so patch 0002 removes those and changes the behavior to
that of any other GUC -- so much so, in fact, that after that patch you
can change the rollback scope in the middle of a transaction, and it
affects from that point onwards.
There is a definite user demand for this feature; almost anyone porting
nontrivial apps from other DBMS systems will want this to be an option.
Of course, the default behavior doesn't change.
Some commercial DBMSs offer only the behavior that this patch
introduces. While they aren't universally loved, they have lots of
users, and many of those users have migrated or are migrating or will
migrate to Postgres in some form or another. Adding this feature lowers
the barrier to such migrations, which cannot be but a good thing. I
think we should add this, and if that means some tools will need to add
a SET line to ensure they get the behavior they need in case careless
DBAs enable this behavior server-wide, that seems not a terribly onerous
cost anyway.
[1] https://postgr.es/m/0A3221C70F24FB45833433255569204D1F6A9286@G01JPEXMBYT05
[2] https://postgr.es/m/20180615202328.7m46qo46v5a5wkd2@alvherre.pgsql
[3] https://postgr.es/m/CA+TgmoavJybY0C8LXHZNcw4p=Eh48yoZwbjq8HVa10qhuP=gpg@mail.gmail.com
--
Álvaro Herrera PostgreSQL Expert, https://www.2ndQuadrant.com/