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
