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 1nvVgG-0007Gw-Pc for pgsql-bugs@arkaria.postgresql.org; Mon, 30 May 2022 03:02:56 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nvVgF-0003cp-Op for pgsql-bugs@arkaria.postgresql.org; Mon, 30 May 2022 03:02:55 +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 1nvVgF-0003cf-GU for pgsql-bugs@lists.postgresql.org; Mon, 30 May 2022 03:02:55 +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 1nvVgD-0000AV-E7 for pgsql-bugs@lists.postgresql.org; Mon, 30 May 2022 03:02:55 +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 24U32nbS3730547; Sun, 29 May 2022 23:02:49 -0400 From: Tom Lane To: David Rowley cc: =?UTF-8?Q?Daniel_Farka=C5=A1?= , Magnus Hagander , PostgreSQL mailing lists Subject: Re: BUG #17502: View based on window functions returns wrong results when queried In-reply-to: References: <17502-281a7aaacfaa872a@postgresql.org> <3722616.1653877139@sss.pgh.pa.us> <3727090.1653878700@sss.pgh.pa.us> Comments: In-reply-to David Rowley message dated "Mon, 30 May 2022 14:51:16 +1200" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3730545.1653879769.1@sss.pgh.pa.us> Date: Sun, 29 May 2022 23:02:49 -0400 Message-ID: <3730546.1653879769@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk David Rowley writes: > On Mon, 30 May 2022 at 14:45, Tom Lane wrote: >> We could leave it alone in the back branches on the grounds that if >> you like the results you get, we shouldn't break it in a minor >> release. > I struggle to see how anyone would like their result correctness to > depend on whether remove_unused_subquery_outputs() is able or unable > to remove a column from the subquery. Indeed, it's unlikely that anybody would like these particular results. But perhaps somebody is running an application that does this and happens to not trip over any obviously-wrong case; for example, if one always selects all columns from this view, the issue is not apparent. I'm not necessarily against adding the prohibition in the back branches. However, if this has been wrong since 10.x (if not further back) then it seems like few people are tripping over the inconsistency. regards, tom lane