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 1muf41-0001Xh-8G for pgsql-hackers@arkaria.postgresql.org; Tue, 07 Dec 2021 18:19:41 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1muf3y-0003tD-TB for pgsql-hackers@arkaria.postgresql.org; Tue, 07 Dec 2021 18:19:38 +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 1muf3y-0003t4-Js for pgsql-hackers@lists.postgresql.org; Tue, 07 Dec 2021 18:19:38 +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 1muf3r-0004oY-S2 for pgsql-hackers@lists.postgresql.org; Tue, 07 Dec 2021 18:19:38 +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 1B7IJT6B3504582; Tue, 7 Dec 2021 13:19:29 -0500 From: Tom Lane To: Robert Haas cc: PostgreSQL Hackers Subject: Re: ExecTypeSetColNames is fundamentally broken In-reply-to: References: <2950001.1638729947@sss.pgh.pa.us> <3360468.1638824732@sss.pgh.pa.us> <3501514.1638898248@sss.pgh.pa.us> Comments: In-reply-to Robert Haas message dated "Tue, 07 Dec 2021 12:58:48 -0500" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3504580.1638901169.1@sss.pgh.pa.us> Date: Tue, 07 Dec 2021 13:19:29 -0500 Message-ID: <3504581.1638901169@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Robert Haas writes: > On Tue, Dec 7, 2021 at 12:30 PM Tom Lane wrote: >> If we consider that the alias renames the columns "for all purposes", >> how is it okay for f() to select the "a" column? > I'd say it isn't. In a green field I'd probably agree with you, but IMO that will break far too much existing SQL code. It'd cause problems for us too, not only end-users. As an example, ruleutils.c would have to avoid attaching new column aliases to tables that are referenced as whole-row Vars. I'm not very sure that that's even possible without creating insurmountable ambiguity issues. There are also fun issues around what happens to a stored query after a table column rename. Right now the query acts as though it uses the old name as a column alias, and that introduces no semantic problem; but that behavior would no longer be acceptable. So the alternatives I see are to revert what bf7ca1587 tried to do here, or to try to make it work that way across-the-board, which implies (a) a very much larger amount of work, and (b) breaking important behaviors that are decades older than that commit. It's not even entirely clear that we could get to complete consistency if we went down that path. regards, tom lane