Re: Code checks for App Devs, using new options for transaction behavior

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Greg Stark <stark(at)mit(dot)edu>
Cc: Simon Riggs <simon(dot)riggs(at)enterprisedb(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Code checks for App Devs, using new options for transaction behavior
Date: 2023-03-23 20:43:32
Message-ID: 2004835.1679604212@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Greg Stark <stark(at)mit(dot)edu> writes:
> On Thu, 27 Oct 2022 at 07:10, Simon Riggs <simon(dot)riggs(at)enterprisedb(dot)com> wrote:
>> * nested transactions = off (default) | all | on
>> Handle nested BEGIN/COMMIT, which can cause chaos on failure.

> I think we've been burned pretty badly by GUCs that control SQL
> semantics before.

Yeah, this idea is an absolute nonstarter. rollback_on_commit seems
excessively dangerous as well compared to the value.

> I think there was discussion at the time nested
> transactions went in and there must have been a reason we did
> SAVEPOINT rather than make nested BEGINs do things like this.

I believe the reason was "because the SQL standard says so".

I'm not sure if any of these proposals are still live now that
Simon's retired. Presumably somebody else would have to push
them forward for there to be a chance of anything happening.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2023-03-23 20:46:03 Re: pg_bsd_indent vs vpath
Previous Message Greg Stark 2023-03-23 20:41:39 Re: Commitfest 2023-03 starting tomorrow!