Am 24.02.2020 um 13:34 schrieb Robert Haas:
> As I said upthread, I think one of the things that would be pretty
> badly broken by this is psql -f something.sql, where something.sql
> contains a series of blocks of the form "begin; something; something;
> something; commit;". Right now whichever transactions succeed get
> committed. With the proposed change, if one transaction block fails,
> it'll merge with all of the following blocks.
No, that's *not* true.
The only difference with the proposed change would be another error in
the logs for the commit following the block with the failed insert.
Note: Nobody has suggested that the commit that returns with an error
should not end the transaction. Do just the same as with any other
commit error in response to a constraint violation!
Am 24.02.2020 um 18:53 schrieb David Fetter:
> On Mon, Feb 24, 2020 at 06:40:16PM +0100, Vik Fearing wrote:
>> On 24/02/2020 18:37, David Fetter wrote:
>>> If we'd done this from a clean sheet of paper, it would have been the
>>> right decision. We're not there, and haven't been for decades.
>> OTOH, it's never too late to do the right thing.
> Some right things take a lot of prep work in order to actually be
> right things. This is one of them. Defaulting to SERIALIZABLE
> isolation is another.
Here the proposed changes is really much much less noticable - please
report the error (again) instead of giving an incomprehensible status
code. Nothing else must be changed - the failing commit should do the
rollback and end the transaction - but it should report this situation
as an error!
Regards Bernhard