Re: BUG #17845: insert into on conflict bug .

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: BUG #17845: insert into on conflict bug .
Дата
Msg-id 4167810.1679062621@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: BUG #17845: insert into on conflict bug .  ("David G. Johnston" <david.g.johnston@gmail.com>)
Ответы Re: BUG #17845: insert into on conflict bug .
Список 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 по дате отправления:

Предыдущее
От: "David G. Johnston"
Дата:
Сообщение: Re: BUG #17845: insert into on conflict bug .
Следующее
От: PG Bug reporting form
Дата:
Сообщение: BUG #17852: gdal34: RPM build broken for RHEL8 and RHEL9 since 2023.01.08