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 1uhERk-00C2cr-IO for pgsql-bugs@arkaria.postgresql.org; Wed, 30 Jul 2025 21:34:49 +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 1uhERj-00CwRE-Ho for pgsql-bugs@arkaria.postgresql.org; Wed, 30 Jul 2025 21:34:47 +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 1uhERj-00CwR6-9f for pgsql-bugs@lists.postgresql.org; Wed, 30 Jul 2025 21:34:47 +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.96) (envelope-from ) id 1uhERg-001jfh-0n for pgsql-bugs@lists.postgresql.org; Wed, 30 Jul 2025 21:34:47 +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 56ULYfEC1675175; Wed, 30 Jul 2025 17:34:41 -0400 From: Tom Lane To: alexandrebailly1955@gmail.com cc: pgsql-bugs@lists.postgresql.org Subject: Re: BUG #19003: A SELECT that does not return a valid table In-reply-to: <19003-17a559220b959ea1@postgresql.org> References: <19003-17a559220b959ea1@postgresql.org> Comments: In-reply-to PG Bug reporting form message dated "Wed, 30 Jul 2025 19:20:14 -0000" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1675173.1753911281.1@sss.pgh.pa.us> Date: Wed, 30 Jul 2025 17:34:41 -0400 Message-ID: <1675174.1753911281@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk PG Bug reporting form writes: > SELECT 'John' AS nom,'James' AS nom > returns a table with attributes nom and nom that I can see in the output. > Returning a table that contains twice the same column should not be > permitted. There is pretty much zero chance that we will enforce that restriction. It would break too much application code. Also, it looks to me like there is no such requirement in the SQL standard. regards, tom lane