From: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
---|---|
To: | 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: | 2024-12-19 16:18:31 |
Message-ID: | 8c384b0d-00f2-4515-8e60-ff7d0d4c093a@eisentraut.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 16.12.24 18:49, Jeff Davis wrote:
> One question I have is whether we want this function to normalize the
> output.
>
> I believe most usecases would want the output normalized, because
> normalization differences (e.g. "a" U+0061 followed by "combining
> acute" U+0301 vs "a with acute" U+00E1) are more minor than differences
> in case.
Can you explain this in further detail? I don't quite follow why this
would be required.
> Of course, a user could wrap it with the normalize() function, but
> that's verbose and easy to forget. I'm also not sure that it can be
> made as fast as a combined function that does both.
>
> And a follow-up question: if it does normalize, the second parameter
> would be the requested normal form. But to accept the keyword forms
> (NFC, NFD in gram.y) rather than the string forms ('NFC', 'NFD') then
> we'd need to also need to add CASEFOLD to gram.y (like NORMALIZE). Is
> that a reasonable thing to do?
That's maybe one reason to keep it separate.
Another might be that's not entirely clear how this should work in
encodings other than UTF-8. For example, the normalized string might
not be representable in the encoding.
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2024-12-19 16:23:11 | Re: Remaining dependency on setlocale() |
Previous Message | Nathan Bossart | 2024-12-19 16:09:35 | Re: connection establishment versus parallel workers |