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