On 1/17/24 5:31 AM, Dominique Devienne wrote:
> Is the pg_statement_rollback technically wrong? Can't what it does be done
> better and more efficiently if it was in the core itself? Is it a lot of
> code?
I took a quick look at that extension, and it's doing pretty much what
you'd do if this was baked into Postgres. The performance penaltiy that
you'll suffer here is that you're going to assign a new transaction ID
for every statement, which can be significantly more expensive than
using one XID per BEGIN/COMMIT (depending of course on how many
statements you have inside a BEGIN/COMMIT).
By the way, you might take a look at Babelfish[1] since it has to solve
this issue as well due to some of the error handling modes that T-SQL
supports.
> Basically implicit-statement-level-rollback is the norm, AFAIK, and
> PostgreSQL is the exception here.
I'm really curious what other databases you've seen that have this
behavior, because the only time I've ever seen it was T-SQL. Way back in
Sybase 11 days it was the only behavior you had, but at some point SQL
Server (and maybe Sybase) added additional options.
Frankly, this paradigm has always seemed completely broken to me. The
entire point of having transactions is so you have all-or-nothing
behavior: either everything works or the transaction aborts. I realize
that automatically rolling a statement back doesn't technically violate
ACID, but IMO it definitely violates the spirit of it. While there are
certainly *some* legitimate uses for rolling a statement back on error,
in 30 years I've seen maybe one scenario where you'd want to roll a
statement back on *any* error, and even then it was only on a specific
statement - not every statement that might get sent to the server.
1: https://babelfishpg.org/
--
Jim Nasby, Data Architect, Austin TX
