Re: Moving to Postgresql database

On Tue, Jan 16, 2024 at 11:05 AM Dominique Devienne <ddevienne(at)gmail(dot)com>
wrote:

> On Tue, Jan 16, 2024 at 5:07 PM Adrian Klaver <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>> 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.
>

Er, *every* statement incurs a round trip to the server. Candidly, I'm
not sure your point here is entirely thought through, unless you are taking
it to mean when writing ad hoc sql written to the console rather than
generally. The savepoint infrastructure directly implements transaction
control, and does it really well. It's both classic, broadly implemented,
and standard.

If you are concerned about round trips in general, you'd want to move to a
function or a procedure, where you have classic exception handling, if/else
blocks, etc, and there are no round trips. postgres really rewards mastery
of server side development practices.

merlin

>