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

From: Branko Radovanovic <branko(dot)radovanovic(dot)zg(at)gmail(dot)com>
To: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
Cc: Vik Fearing <vik(at)postgresfriends(dot)org>, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #17853: COLLATE does not work with numeric column references in ORDER BY
Date: 2023-03-19 09:34:46
Message-ID: CAH70sp7SLk-UgdQyNToggCkJRRycKXSyaiNUQEx7gxocTPedPQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Indeed, my initial instinct was to report this as a documentation bug.
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.

However, this (fairly dumb) SQL will still work:

values ('a', 'b'), ('c', 'd')
order by 1 desc, column2 collate "C"

...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). On the other hand, the benefit of
doing either may - granted - be close to zero in this particular case.

B.

On Sun, Mar 19, 2023 at 2:28 AM David G. Johnston <
david(dot)g(dot)johnston(at)gmail(dot)com> wrote:

> On Sat, Mar 18, 2023 at 6:11 PM David G. Johnston <
> david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
>
>> On Sat, Mar 18, 2023 at 5:56 PM Vik Fearing <vik(at)postgresfriends(dot)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(dot)radovanovic(dot)zg(at)gmail(dot)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.
>
>

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Alexander Korotkov 2023-03-19 17:08:28 Re: BUG #17847: Unaligned memory access in ltree_gist
Previous Message David Rowley 2023-03-19 09:33:34 Re: BUG #17844: Memory consumption for memoize node