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 1sp7iq-00GmHE-Bx for pgsql-hackers@arkaria.postgresql.org; Fri, 13 Sep 2024 14:56:33 +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 1sp7ip-004Udp-RB for pgsql-hackers@arkaria.postgresql.org; Fri, 13 Sep 2024 14:56:31 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sp7ip-004UZH-Ge for pgsql-hackers@lists.postgresql.org; Fri, 13 Sep 2024 14:56:31 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sp7il-0010QQ-N9 for pgsql-hackers@lists.postgresql.org; Fri, 13 Sep 2024 14:56:30 +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 48DEuJSx086137; Fri, 13 Sep 2024 10:56:19 -0400 From: Tom Lane To: Denis Garsh cc: "pgsql-hackers@lists.postgresql.org" Subject: Re: Add system column support to the USING clause In-reply-to: <333431726204057@mail.yandex.ru> References: <333431726204057@mail.yandex.ru> Comments: In-reply-to Denis Garsh message dated "Fri, 13 Sep 2024 11:03:42 +0300" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <86135.1726239379.1@sss.pgh.pa.us> Date: Fri, 13 Sep 2024 10:56:19 -0400 Message-ID: <86136.1726239379@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Denis Garsh writes: > The patch adds support for system columns in JOIN USING clause. I think this is an actively bad idea, and it was likely intentional that it's not supported today. A few reasons why: * There are, fundamentally, no use-cases for joining on system columns. The only one that is stable enough to even consider using for the purpose is tableoid, and I'm not detecting a reason why that'd be useful. If there are any edge cases where people would actually wish to do that, it can be done easily enough with a standard JOIN ON clause. * Non-heap table AMs may not provide the same system columns that heap does, further reducing the scope for plausible use-cases. (Yeah, I know we don't support that too well today.) * This breaks ruleutils.c's mechanism for dealing with name conflicts across multiple USING clauses. That relies on being able to assign aliases to the USING inputs at the table level (that is, "FROM realtable AS aliastable(aliascolumn,...)"). There's no way to alias a system column in the FROM syntax. regards, tom lane