Re: COMMIT IN STORED PROCEDURE WHILE IN A LOOP

From: Christophe Pettus <xof(at)thebuild(dot)com>
To: Bryn Llewellyn <bryn(at)yugabyte(dot)com>
Cc: Ravi Krishna <s_ravikrishna(at)aol(dot)com>, pgsql-general list <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: COMMIT IN STORED PROCEDURE WHILE IN A LOOP
Date: 2022-10-18 21:35:27
Message-ID: 408C4DF8-2F05-401A-B4BC-FAAAFE79CA49@thebuild.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

> On Oct 18, 2022, at 14:15, Bryn Llewellyn <bryn(at)yugabyte(dot)com> wrote:
> Could the limitation be lifted by making tractable internal implementation changes? Or is it rooted in profoundly deep features of the architecture—meaning that it could never be lifted?

That is a very good question. One of the issues (as I understand it) is to be able to continue to use the same connection in the event of an error. Here's the scenario:

1. SELECT * FROM my_func();

2. my_func gets an error. The connection is now in an error state.

3. So, catching the exception doesn't do you much good, because future operations will get an error.

This problem is solved by wrapping it in a savepoint, since rolling back to the savepoint will undo the error state of the connection.

There might be a way forward, but it's hard to get the proper semantics of an exception handler without doing something like that.

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Ted Toth 2022-10-18 21:41:43 what's inherited
Previous Message Tom Lane 2022-10-18 21:33:37 Re: COMMIT IN STORED PROCEDURE WHILE IN A LOOP