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 1uhPPh-00EGaU-PR for pgsql-bugs@arkaria.postgresql.org; Thu, 31 Jul 2025 09:17:26 +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 1uhPPf-00EXto-TE for pgsql-bugs@arkaria.postgresql.org; Thu, 31 Jul 2025 09:17:24 +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 1uhPPf-00EXtg-HM for pgsql-bugs@lists.postgresql.org; Thu, 31 Jul 2025 09:17:23 +0000 Received: from relay1-d.mail.gandi.net ([2001:4b98:dc4:8::221]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1uhPPb-001ooC-2E for pgsql-bugs@lists.postgresql.org; Thu, 31 Jul 2025 09:17:23 +0000 Received: by mail.gandi.net (Postfix) with ESMTPSA id 6F35A43270; Thu, 31 Jul 2025 09:17:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=postgresfriends.org; s=gm1; t=1753953435; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=EeJfvD14I23D3cdsjJ4iHOCvxOgdmUECqZ9hwijq7Lg=; b=G6/ZYMS3yufROVi4/dTgr86n9Dt7qXjeVJBK3cUu/lAXHxwFL7DNU+SV4/8qusyNIzovKa iAu+6Z+Dm4hBwCJHLCoMgGg1kPdApp9+yZgkrrPont2BktIF2v/Fi1ITDO2/zYcK1Zl9It EwJAXJpP5V3hQ8BT0/Bic5TNlgmjJY5WtePKdLHQ4V/QHcyEms6gphOS0kekWLN9mSjvtx p/ftJA+1WBaBAJDcNxR/SDVW3KZQm2SQfwOSg1uWj1+D4g2Z3nCrkdSYBkgp85AT2FXcX2 2tw4D0nUPuPo/1STJp3fmSHySXHTjWU8gERFhhVLBR6lBV9BW8Cvcface+iM5g== Content-Type: multipart/alternative; boundary="------------xETzYcqygKiSCSQ3jdxGOIOw" Message-ID: Date: Thu, 31 Jul 2025 11:17:14 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: BUG #19003: A SELECT that does not return a valid table To: Tom Lane , alexandrebailly1955@gmail.com Cc: pgsql-bugs@lists.postgresql.org References: <19003-17a559220b959ea1@postgresql.org> <1675174.1753911281@sss.pgh.pa.us> Content-Language: en-US From: Vik Fearing In-Reply-To: <1675174.1753911281@sss.pgh.pa.us> X-GND-State: clean X-GND-Score: 0 X-GND-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdefgddutddtgeefucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuifetpfffkfdpucggtfgfnhhsuhgsshgtrhhisggvnecuuegrihhlohhuthemuceftddunecunecujfgurheptgfkffggfgfuvfevfhfhjgesrgdtreertddvjeenucfhrhhomhepgghikhcuhfgvrghrihhnghcuoehvihhksehpohhsthhgrhgvshhfrhhivghnughsrdhorhhgqeenucggtffrrghtthgvrhhnpeehheevgfelvefhjeegheegteegleevjeegteeuffdtfeefledufffhtdffffeufeenucffohhmrghinhepihhsohdrohhrghenucfkphepvdgrtddvmeekgedvkeemudduvgdtmedvjedtudemjeduieefmeelkeejvdemrgdtuddvmeduvdelfeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepihhnvghtpedvrgdtvdemkeegvdekmeduudgvtdemvdejtddumeejudeifeemleekjedvmegrtdduvdemuddvleefpdhhvghloheplgfkrfggieemvdgrtddvmeekgedvkeemudduvgdtmedvjedtudemjeduieefmeelkeejvdemrgdtuddvmeduvdelfegnpdhmrghilhhfrhhomhepvhhikhesphhoshhtghhrvghsfhhrihgvnhgushdrohhrghdpnhgspghrtghpthhtohepfedprhgtphhtthhopehtghhlsehsshhsrdhpghhhrdhprgdruhhspdhrtghpthhtoheprghlvgigrghnughrvggsrghilhhlhiduleehheesghhmrghilhdrtghomhdprhgtphhtthhopehpg hhsqhhlqdgsuhhgsheslhhishhtshdrphhoshhtghhrvghsqhhlrdhorhhg X-GND-Sasl: vik@postgresfriends.org List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk This is a multi-part message in MIME format. --------------xETzYcqygKiSCSQ3jdxGOIOw Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 30/07/2025 23:34, Tom Lane wrote: > 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. Indeed.  In SQL:2023-1 (available free of charge at [1]) says in Subclause 4.6, "Tables":     "An operation that references zero or more base tables and returns a table is called a *query*. The result of a query is called a *derived table*." and     "Derived tables, other than viewed tables, may contain more than one column with the same name." So, not only is this not a bug we should fix, it is explicitly allowed by the standard. [1] https://www.iso.org/standard/76583.html -- Vik Fearing --------------xETzYcqygKiSCSQ3jdxGOIOw Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit


On 30/07/2025 23:34, Tom Lane wrote:
PG Bug reporting form <noreply@postgresql.org> 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.


Indeed.  In SQL:2023-1 (available free of charge at [1]) says in Subclause 4.6, "Tables":


    "An operation that references zero or more base tables and returns a table is called a *query*. The result of a query is called a *derived table*."


and


    "Derived tables, other than viewed tables, may contain more than one column with the same name."


So, not only is this not a bug we should fix, it is explicitly allowed by the standard.


[1] https://www.iso.org/standard/76583.html

-- 

Vik Fearing

--------------xETzYcqygKiSCSQ3jdxGOIOw--