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 1pdyC3-00063E-FV for pgsql-bugs@arkaria.postgresql.org; Sun, 19 Mar 2023 18:55:47 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pdyB3-00041K-Kd for pgsql-bugs@arkaria.postgresql.org; Sun, 19 Mar 2023 18:54:45 +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 1pdyB3-00041B-Ax for pgsql-bugs@lists.postgresql.org; Sun, 19 Mar 2023 18:54:45 +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 1pdyB0-0000IJ-NH for pgsql-bugs@lists.postgresql.org; Sun, 19 Mar 2023 18:54:44 +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 32JIseBY744632; Sun, 19 Mar 2023 14:54:40 -0400 From: Tom Lane To: Branko Radovanovic cc: "David G. Johnston" , Vik Fearing , pgsql-bugs@lists.postgresql.org Subject: Re: BUG #17853: COLLATE does not work with numeric column references in ORDER BY In-reply-to: References: <17853-57fa4c939f613eb6@postgresql.org> <3b32d6df-c6a4-c3fa-0eef-d4e2a8789fb6@postgresfriends.org> Comments: In-reply-to Branko Radovanovic message dated "Sun, 19 Mar 2023 10:34:46 +0100" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <744630.1679252080.1@sss.pgh.pa.us> Date: Sun, 19 Mar 2023 14:54:40 -0400 Message-ID: <744631.1679252080@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Branko Radovanovic writes: > COLLATE is a good place to de-support numeric references because ORDER BY 1 > COLLATE "C" is then unambiguously an error, rather than a silent fail. Yup. > ...so in the grand scheme of things it doesn't really help. Sometimes it's > actually easier to implement something than explain (in the doc) how or why > it doesn't work (as expected or at all). It's not that any specific choice of semantics would be hard to implement. It's that the syntax is fundamentally ambiguous, so if you get too aggressive about saying "we'll resolve ambiguous cases like this" then you risk queries silently doing something other than what the user expected, giving rise to a different set of bug reports. The back story here is that SQL92 said "the argument of ORDER BY is an output column name or number", but SQL99 reversed course and said "the argument of ORDER BY is an expression over the input columns". So "ORDER BY 1" means two completely different things depending on which spec version you read. We didn't (and still don't) want to give up compatibility with SQL92's way, for backwards-compatibility reasons and because it's such a handy shortcut in many cases. But we use the SQL92 interpretation only when the clause satisfies SQL92 exactly. "COLLATE" wasn't in SQL92; so if we did what you claim we should do we would be applying SQL92 semantics to a query that isn't even legal SQL92 syntax, while failing to comply with SQL99 for a query that *is* legal SQL99. I like throwing an error better than either of those choices, so I'm perfectly satisfied with the code's behavior as-is. What seems open for debate is whether the documentation needs to address this case specifically. I think it's already sufficiently implied by [1], but perhaps it isn't. regards, tom lane [1] https://www.postgresql.org/docs/current/queries-order.html