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 1mYspw-000891-0Y for pgsql-bugs@arkaria.postgresql.org; Fri, 08 Oct 2021 16:35:08 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1mYspt-0002I8-0H for pgsql-bugs@arkaria.postgresql.org; Fri, 08 Oct 2021 16:35:05 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mYsps-0002Hc-Pd for pgsql-bugs@lists.postgresql.org; Fri, 08 Oct 2021 16:35:04 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mYspq-000546-Pa for pgsql-bugs@lists.postgresql.org; Fri, 08 Oct 2021 16:35:03 +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 198GZ15D236281; Fri, 8 Oct 2021 12:35:01 -0400 From: Tom Lane To: "Narayanan Iyer" cc: pgsql-bugs@lists.postgresql.org, support@yottadb.com Subject: Re: GROUP BY using tablename.* does not work if tablename has 1 column with NULL values In-reply-to: <0e0301d7bc59$a1e416b0$e5ac4410$@yottadb.com> References: <0e0301d7bc59$a1e416b0$e5ac4410$@yottadb.com> Comments: In-reply-to "Narayanan Iyer" message dated "Fri, 08 Oct 2021 11:31:57 -0400" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <236279.1633710901.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Fri, 08 Oct 2021 12:35:01 -0400 Message-ID: <236280.1633710901@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk "Narayanan Iyer" writes: > In the below example, t1 points to a table with just 1 column (lastName)= and so I expect the 2 SELECT queries (pasted below) using t1.lastName or = t1.* syntax to produce the exact same results. But the latter produces one= extra row of output (3 rows vs 2 rows). I don't see any bug here. If you take out the grouping it's a bit easier to see what's going on: SELECT *, t1.*::record FROM tmp t2 LEFT JOIN (SELECT lastName FROM tmp) AS= t1 ON (t2.firstName <=3D 'Acid'); id | firstname | lastname | lastname | t1 = ----+-----------+----------+----------+-------- 1 | Acid | Burn | Burn | (Burn) 1 | Acid | Burn | | () 2 | Joey | | | = (3 rows) The first row comes from joining t2 Acid,Burn to t1 Acid,Burn. The second row comes from joining t2 Acid,Burn to t1 Joey,NULL. The third row comes from failing to join t2 Joey,NULL to anything. So in the second row, there is a matched t1 row, and t1.* therefore represents a non-null composite value that happens to contain one null field. In the third row, there is no matched t1 row at all, so we consider that t1.* is a composite NULL, which is different from a composite containing NULL fields. You can argue about whether composite NULL ought to be considered identical to ROW(NULL). But there are a lot of contexts where that would be a bad idea, and very few where it'd be good. = > It seems like a Postgres bug to me. Not sure if there is a Postgres sett= ing that I need to enable in order to avoid this discrepancy. You might be able to get the results you want by explicitly converting to row-containing-nulls, which is not very hard: SELECT *, row(t1.*) FROM tmp t2 LEFT JOIN (SELECT lastName FROM tmp) AS t= 1 ON (t2.firstName <=3D 'Acid'); id | firstname | lastname | lastname | row = ----+-----------+----------+----------+-------- 1 | Acid | Burn | Burn | (Burn) 1 | Acid | Burn | | () 2 | Joey | | | () (3 rows) regards, tom lane