Re: BUG #17853: COLLATE does not work with numeric column references in ORDER BY
От | Tom Lane |
---|---|
Тема | Re: BUG #17853: COLLATE does not work with numeric column references in ORDER BY |
Дата | |
Msg-id | 744631.1679252080@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #17853: COLLATE does not work with numeric column references in ORDER BY (Branko Radovanovic <branko.radovanovic.zg@gmail.com>) |
Список | pgsql-bugs |
Branko Radovanovic <branko.radovanovic.zg@gmail.com> 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
В списке pgsql-bugs по дате отправления: