Re: Moving to Postgresql database

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

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