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