Re: BUG #17845: insert into on conflict bug . - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #17845: insert into on conflict bug .
Date
Msg-id 4167810.1679062621@sss.pgh.pa.us
Whole thread Raw
In response to Re: BUG #17845: insert into on conflict bug .  ("David G. Johnston" <david.g.johnston@gmail.com>)
Responses Re: BUG #17845: insert into on conflict bug .  (Peter Geoghegan <pg@bowt.ie>)
List pgsql-bugs
"David G. Johnston" <david.g.johnston@gmail.com> writes:
> On Thursday, March 16, 2023, 德哥 <digoal@126.com> wrote:
>> In this case, `where a.ts < exclude. ts` and `order by ts desc` are used.
>> The ts of the tuple inserted first is the largest. So why throw an error?
>> Throwing an error here is obviously not logically correct.

> You’d get a duplicate value violation instead.  As it stands, which error
> you get is somewhat non-deterministic, but you will get one.

I'm going to push back against the idea that "the tuple inserted first"
is a well-defined concept.  SQL is a set-oriented language and in
principle all the row changes caused by a single statement happen
concurrently/independently.  Of course we all know that real
implementations typically don't do it like that, but they do take
advantage of the freedom to do the updates in any order.  So the
reason we throw an error here is to prevent cases where the happenstance
of the individual actions' order would affect the end result.

The bottom line is that it *is* happenstance, ORDER BY or no: the
implementation is not bound to preserve the order of rows coming out
of a sub-select.

            regards, tom lane



pgsql-bugs by date:

Previous
From: "David G. Johnston"
Date:
Subject: Re: BUG #17845: insert into on conflict bug .
Next
From: PG Bug reporting form
Date:
Subject: BUG #17852: gdal34: RPM build broken for RHEL8 and RHEL9 since 2023.01.08