| From: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
|---|---|
| To: | fn ln <emuser20140816(at)gmail(dot)com> |
| Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, Andres Freund <andres(at)anarazel(dot)de>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: BUG #15977: Inconsistent behavior in chained transactions |
| Date: | 2019-09-07 17:04:38 |
| Message-ID: | alpine.DEB.2.21.1909071900170.15836@lancre |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs pgsql-hackers |
>> Now, I'd prefer error in all cases, no doubt about that, which might be
>> considered a regression. A way around that could be to have a GUC decide
>> between a strict behavior (error) and the old behavior (warning).
>
> I think it's more better to have a GUC to disable implicit transaction
> 'block' feature, because that's probably the root of all issues.
Hmmm… I'm not sure that erroring out on "SELECT 1" because there is no
explicit "BEGIN" is sellable, even under some GUC.
--
Fabien.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | fn ln | 2019-09-07 17:31:58 | Re: BUG #15977: Inconsistent behavior in chained transactions |
| Previous Message | fn ln | 2019-09-07 16:32:17 | Re: BUG #15977: Inconsistent behavior in chained transactions |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | fn ln | 2019-09-07 17:31:58 | Re: BUG #15977: Inconsistent behavior in chained transactions |
| Previous Message | fn ln | 2019-09-07 16:32:17 | Re: BUG #15977: Inconsistent behavior in chained transactions |