Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sazDg-00CpbR-BQ for pgsql-general@arkaria.postgresql.org; Mon, 05 Aug 2024 15:01:56 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1sazDe-00EOXw-Sg for pgsql-general@arkaria.postgresql.org; Mon, 05 Aug 2024 15:01:54 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sazDe-00EOXn-HV for pgsql-general@lists.postgresql.org; Mon, 05 Aug 2024 15:01:54 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sazDc-003Eeg-0f for pgsql-general@lists.postgresql.org; Mon, 05 Aug 2024 15:01:53 +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 475F1oiX1073702; Mon, 5 Aug 2024 11:01:50 -0400 From: Tom Lane To: Dominique Devienne cc: pgsql-general@lists.postgresql.org Subject: Re: UPDATE-FROM and INNER-JOIN In-reply-to: References: <1064261.1722866217@sss.pgh.pa.us> Comments: In-reply-to Dominique Devienne message dated "Mon, 05 Aug 2024 16:36:33 +0200" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1073700.1722870110.1@sss.pgh.pa.us> Date: Mon, 05 Aug 2024 11:01:50 -0400 Message-ID: <1073701.1722870110@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Dominique Devienne writes: > The reason I find the restriction damaging is that `FROM t1, t2 WHERE > t1.c1 = t2.c2` > is the "old" way to write joins, versus the "newer" `FROM t1 JOIN t2 > ON t1.c1 = t2.c2` > which IMHO better separates "filtering" from "joining" columns. FWIW. But the whole point of that syntax is to be explicit about which tables the ON clause(s) can draw from. If we had a more complex FROM clause, with say three or four JOINs involved, which part of that would you argue the UPDATE target table should be implicitly inserted into? The only thing that would be non-ambiguous would be to require the target table to be explicitly named in FROM (and not treat that as a self-join, but as the sole scan of the target table). Some other RDBMSes do it like that, but it seems like too much of a compatibility break for us. Sadly, the SQL spec doesn't provide for a FROM clause in UPDATE, so they offer no guidance. But I doubt we are going to change this unless the standard defines it and does so in a way that doesn't match what we're doing. regards, tom lane