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 1pIAe0-0001SS-6H for pgsql-hackers@arkaria.postgresql.org; Wed, 18 Jan 2023 15:46:32 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pIAdy-0004UN-S6 for pgsql-hackers@arkaria.postgresql.org; Wed, 18 Jan 2023 15:46:30 +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 1pIAdy-0004UD-J4 for pgsql-hackers@lists.postgresql.org; Wed, 18 Jan 2023 15:46:30 +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 1pIAdw-0000AO-FL for pgsql-hackers@lists.postgresql.org; Wed, 18 Jan 2023 15:46:29 +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 30IFkOJd3574545; Wed, 18 Jan 2023 10:46:24 -0500 From: Tom Lane To: Dean Rasheed cc: David Rowley , Richard Guo , Ronan Dunklau , Justin Pryzby , Pavel Luzanov , pgsql-hackers@lists.postgresql.org, Ranier Vilela Subject: Re: Add proper planner support for ORDER BY / DISTINCT aggregates In-reply-to: References: <3163474.aeNJFYEL58@aivenronan> <9f61ddbf-2989-1536-b31e-6459370a6baa@postgrespro.ru> <2202180.iZASKD2KPV@aivenlaptop> <416296.1673411524@sss.pgh.pa.us> <2909364.1673939119@sss.pgh.pa.us> Comments: In-reply-to Dean Rasheed message dated "Wed, 18 Jan 2023 10:52:24 +0000" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3574543.1674056784.1@sss.pgh.pa.us> Date: Wed, 18 Jan 2023 10:46:24 -0500 Message-ID: <3574544.1674056784@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Dean Rasheed writes: > I think the behaviour of an ORDER BY in the query can also be pretty > surprising. Indeed. The fundamental question is this: in > SELECT ARRAY[random(), random(), random()] > FROM generate_series(1, 3) > ORDER BY random(); are those four occurrences of random() supposed to refer to the same value, or not? This only matters for volatile functions of course; with stable or immutable functions, textually-equal subexpressions should have the same value in any given row. It is very clear what we are supposed to do for SELECT random() FROM ... ORDER BY 1; which sadly isn't legal SQL anymore. It gets fuzzy as soon as we have SELECT random() FROM ... ORDER BY random(); You could make an argument either way for those being the same value or not, but historically we've concluded that it's more useful to deem them the same value. Then the behavior you show is not such a surprising extension, although it could be argued that such matches should only extend to identical top-level targetlist entries. > The trouble is, if we tried to fix that, we'd risk changing some other > behaviour that users may have come to rely on. Yeah. I'm hesitant to try to adjust semantics here; we're much more likely to get complaints than kudos. regards, tom lane