On Mon, Sep 4, 2023 at 3:47 PM Erik Wienhold <ewie@xxxxxxxxx> wrote:
On 04/09/2023 11:51 CEST Lorusso Domenico <domenico.l76@xxxxxxxxx> 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
