| From: | Vik Fearing <vik(at)postgresfriends(dot)org> |
|---|---|
| To: | Peter Eisentraut <peter(at)eisentraut(dot)org>, Jeff Davis <pgsql(at)j-davis(dot)com>, Joe Conway <mail(at)joeconway(dot)com>, Ian Lawrence Barwick <barwick(at)gmail(dot)com> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Add CASEFOLD() function. |
| Date: | 2025-06-19 16:21:09 |
| Message-ID: | 7ee0ad52-650b-472f-82f4-27d2cf1a0887@postgresfriends.org |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 19/06/2025 16:47, Peter Eisentraut wrote:
> On 17.06.25 17:37, Vik Fearing wrote:
>> For <fold> (which includes LOWER() and UPPER()), the text says in
>> Section 6.35 GR 7.e:
>>
>>
>> If the character set of <character factor> is UTF8, UTF16, or UTF32,
>> then FR is replaced by
>> Case:
>> i) If the <search condition> S IS NORMALIZED evaluates to
>> True, then NORMALIZE (FR)
>> ii) Otherwise, FR.
>>
>>
>> Here, FR is the result of the function and S is its argument.
>>
>>
>> It does not appear to me that our LOWER and UPPER functions obey this
>> rule, so there is a valid argument that we should continue to ignore
>> it. Or, we can say that we have at least one of three compliant.
>
> The SQL standard also says in a few other places that normalization
> should be applied, and we do none of those, so this is probably not a
> reason to change CASEFOLD at this point.
>
Works for me.
--
Vik Fearing.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jeff Davis | 2025-06-19 16:33:41 | Re: Add CASEFOLD() function. |
| Previous Message | Robert Treat | 2025-06-19 16:15:48 | Re: Add CASEFOLD() function. |