Re: Moving to Postgresql database

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Dominique Devienne <ddevienne(at)gmail(dot)com>
Cc: Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>, veem v <veema0000(at)gmail(dot)com>, pgsql-general <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: Moving to Postgresql database
Date: 2024-01-16 21:59:10
Message-ID: 1904120.1705442350@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Dominique Devienne <ddevienne(at)gmail(dot)com> writes:
> But sure, I take your point, you can emulate statement-level (implicit)
> rollback via an explicit SAVEPOINT, and ROLLBACK to the savepoint instead.

> But my point remains, that something like what that extension does should
> be an option of PostgreSQL itself, not an extension. --DD

> PS: I'd also be happy to hear why it's not, or won't be, on technical terms.

The reason it's not going to happen is that the community (or at least
the more senior developers) still remembers what happened the last
time we tried it.

We did implement server-side auto-rollback years ago in PG 7.3,
and it was enough of a disaster that we took it out again in 7.4.
The problem is that now you have a switch somewhere (whether a GUC
or something else, still a switch) that fundamentally changes the
transactional semantics seen by applications. Run an application
in the wrong mode and you have a broken app. Worse, there is an
awful lot of client-side code that now has to cope with both
behaviors. We thought that would be okay ... well, it wasn't.
It was a mess. It would be a bigger mess now if we were to try it
again, because there would be even more broken client code.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message hector vass 2024-01-16 22:07:16 Re: Mimic ALIAS in Postgresql?
Previous Message Emanuel Calvo 2024-01-16 21:53:34 Re: replication isn't replicating