Re: Moving to Postgresql database

On Tue, Jan 16, 2024 at 12:10 PM Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>
wrote:

> On 1/16/24 09:04, Dominique Devienne wrote:
> > On Tue, Jan 16, 2024 at 5:07 PM Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com
> > <mailto:adrian(dot)klaver(at)aklaver(dot)com>> wrote:
> >
> > On 1/16/24 00:06, Dominique Devienne wrote:
> > > On Mon, Jan 15, 2024 at 5:17 AM veem v <veema0000(at)gmail(dot)com
> > <mailto:veema0000(at)gmail(dot)com>
> > > <mailto:veema0000(at)gmail(dot)com <mailto:veema0000(at)gmail(dot)com>>> 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.
>

Performance-killing alternatives are not really altternatives.