On Tue, Jan 16, 2024 at 6:10 PM Adrian Klaver <adrian.klaver@xxxxxxxxxxx> wrote:
On 1/16/24 09:04, Dominique Devienne wrote:
> On Tue, Jan 16, 2024 at 5:07 PM Adrian Klaver <adrian.klaver@xxxxxxxxxxx
> <mailto:adrian.klaver@xxxxxxxxxxx>> wrote:
>
> On 1/16/24 00:06, Dominique Devienne wrote:
> > On Mon, Jan 15, 2024 at 5:17 AM veem v <veema0000@xxxxxxxxx
> <mailto:veema0000@xxxxxxxxx>
> > <mailto:veema0000@xxxxxxxxx <mailto:veema0000@xxxxxxxxx>>> wrote:
> > Is any key design/architectural changes should the app
> development
> > team [...], should really aware about
> > Hi. One of the biggest pitfall of PostgreSQL, from the app-dev
> perspective,
> > is the fact any failed statement fails the whole transaction, with
> > ROLLBACK as the only recourse.
>
> "SAVEPOINT establishes a new savepoint within the current transaction.
>
>
> I wish it was that easy.
> I've been scared away from using them, after reading a few articles...
> Also, that incurs extra round trips to the server, from the extra commands.
The point was that '... with ROLLBACK as the only recourse.' is not the
case. There is an alternative, whether you want to use it being a
separate question.
Technically, it's still a ROLLBACK, so that is indeed the only recourse.
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.
