Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pdAtV-0000HU-PA for pgsql-bugs@arkaria.postgresql.org; Fri, 17 Mar 2023 14:17:21 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pdAtS-0007JQ-VH for pgsql-bugs@arkaria.postgresql.org; Fri, 17 Mar 2023 14:17:18 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pdAtS-0007JH-Mz for pgsql-bugs@lists.postgresql.org; Fri, 17 Mar 2023 14:17:18 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pdAtP-00087X-Jb for pgsql-bugs@lists.postgresql.org; Fri, 17 Mar 2023 14:17:18 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 32HEH1wt4167811; Fri, 17 Mar 2023 10:17:01 -0400 From: Tom Lane To: "David G. Johnston" cc: =?UTF-8?B?5b635ZOl?= , jian he , "pgsql-bugs@lists.postgresql.org" Subject: Re: BUG #17845: insert into on conflict bug . In-reply-to: References: <17845-fee889ae7e226a76@postgresql.org> <5a1545f3.1e8a.186ed6b8959.Coremail.digoal@126.com> Comments: In-reply-to "David G. Johnston" message dated "Fri, 17 Mar 2023 05:19:40 -0700" MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-ID: <4167809.1679062621.1@sss.pgh.pa.us> Content-Transfer-Encoding: 8bit Date: Fri, 17 Mar 2023 10:17:01 -0400 Message-ID: <4167810.1679062621@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk "David G. Johnston" writes: > On Thursday, March 16, 2023, 德哥 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