Re: BUG #17853: COLLATE does not work with numeric column references in ORDER BY

On Sat, Mar 18, 2023 at 6:11 PM David G. Johnston <david.g.johnston@gmail.com> wrote:

On Sat, Mar 18, 2023 at 5:56 PM Vik Fearing <vik@postgresfriends.org> wrote:

On 3/18/23 23:44, PG Bug reporting form wrote:
> The following bug has been logged on the website:
>
> Bug reference:      17853
> Logged by:          Branko Radovanovic
> Email address:      branko.radovanovic.zg@gmail.com
> PostgreSQL version: 13.4
> Operating system:   Debian
> Description:
>
> The following SQL:
>
> values ('a')
> order by 1 collate "C";
>
> ...returns an error: SQL Error [42804]: ERROR: collations are not supported
> by type integer
>
> In the above query, "1" is not an integer but a column reference, so it
> should be treated as well-formed and work the same as with the actual column
> label:

There is an argument that this should work.  There is also an argument
that using numerical column references is not (or rather, is no longer)
Standard SQL and should not be used.

So we also have a documentation bug for failing to accurately indicate that our treatment here is non-standard.  Given the existing notes that refer to both SQL-92 and SQL:1999 explicitly and make no mention of this I'd have to assume such a material difference falls into the scope of things we document.

I'll correct myself - the original bug report is indeed not actually a bug.  We do not document nor promise the expected behavior.  Anything that is more than a simple integer number or a column name is by its nature an "...arbitrary expression formed from input-column values."  In particular, the syntax doesn't allow for any place to attach COLLATE to the number like it does for ASC etc... Though here the number of input columns referenced is zero, you just have a constant, thus pointless, order by expression.  Which is documented as being allowed.

I wouldn't completely discount the possibility of adding a note about this in the documentation, but it hasn't ever come up, the section is long enough as-is, and the error is consistently reported for the case.

David J.