Christophe Pettus writes:
> That's an interesting question. It appears to be a no-op, although a quick
> scan of the code doesn't reveal why. Here's an illustrative test case:
This test case would be less confusing if the outer handler did
RAISE NOTICE 'in outer exception handler: %', sqler
> On Mar 22, 2025, at 21:37, Kevin Stephenson wrote:
>
> Christophe and Tom, thank you for your responses, but I'm still a bit
> confused. In my original email, the Test 2 case is allowing a ROLLBACK in the
> EXCEPTION clause without throwing an error. Is it a NOP ROLLBACK being
> applied t
Kevin Stephenson writes:
> Christophe and Tom, thank you for your responses, but I'm still a bit
> confused. In my original email, the Test 2 case is allowing a ROLLBACK in the
> EXCEPTION clause without throwing an error. Is it a NOP ROLLBACK being
> applied to an aborted subTX, a real full RO
lease advise.
Thanks,
Kevin Stephenson
From: Tom Lane
Sent: Saturday, March 22, 2025 7:59 AM
To: Christophe Pettus
Cc: Kevin Stephenson ; pgsql-gene...@postgresql.org
Subject: Re: Nested Stored Procedures - ERROR: invalid transaction termination
2D000
Chris
Christophe Pettus writes:
> A procedure cannot issue top-level transaction control statements from within
> an exception block, and attempting to do so raises the error you saw. This
> includes procedures that are called from within an exception block.
Yeah. Postgres doesn't have autonomous t
Hello,
> On Mar 22, 2025, at 08:38, Kevin Stephenson wrote:
> • When a top-level stored procedure is called it implicitly creates a TX
> if there is no current TX.
> • When a BEGIN/EXCEPTION block is used it implicitly creates a subTX for
> that block.
These statements are correct.
>
Hi all,
I'm assessing the feasibility of implementing a full featured "DB as API"
concept in PostgreSQL (PG) and have run across an apparent inconsistency in the
transaction (TX) handling behavior with nested stored procedures. This apparent
inconsistency is present in both 16.4 and 17.4 runnin
