Re: rollback to savepoint issue

On Mon, Sep 4, 2023 at 3:47 PM Erik Wienhold <ewie(at)ewie(dot)name> wrote:

> On 04/09/2023 11:51 CEST Lorusso Domenico <domenico(dot)l76(at)gmail(dot)com> wrote:
> Transaction control is not possible in functions. Only in procedures
> (CALL)
> and DO blocks.
>
> > ERROR: syntax error at or near "to"
> > LINE 41: rollback to savepoint deleteAttribute;
>
> Use BEGIN ... EXCEPTION ... END instead of manual savepoints. [1]
>
> [1]
> https://www.postgresql.org/docs/current/plpgsql-porting.html#PLPGSQL-PORTING-EXCEPTIONS

Hi Erik. And experts at large. What's the underlying mechanism though? An
implicit SAVEPOINT?

The reason I'm asking, is that we are using explicit SAVEPOINTs in client
C/C++ code,
to "emulate" per-Statement "isolation", like other DBs have (Oracle,
SQLite), instead of
having to ROLLBACK the "whole" transaction.

Which means extra explicit round-trips to the server to establish and "move
along" the savepoint,
per command. Which I think is "expensive". So would anonymous DO blocks be
a better solution?
If BEGIN/EXCEPTION uses an "implicit" / "hidden" SAVEPOINT, would that
still be better then?

And if we switch to anon DO+EXCEPTION blocks, is it just as easy to bind to
the inner SQL command(s)?

Sorry if my questions are a little vague. This is an area that's still
fuzzy for me, I'm not versed in pgPL/SQL.

Finally, I've read "horror stories" about SAVEPOINTs, with
performance-cliffs when using them,
because if I recall correctly, there's only room in pages (?) to deal with
just a few efficiently,
before additional "storage" must be allocated somewhere else, leading to
contention. Does that
apply to that BEGIN+EXCEPTION mechanism too?

Thanks for any insights. --DD