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
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! |