Horton

Re: Add CASEFOLD() function.

Jeff Davis <pgsql@j-davis.com>

View thread
From: Jeff Davis <pgsql@j-davis.com>
To: Peter Eisentraut <peter@eisentraut.org>, Joe Conway <mail@joeconway.com>, Ian Lawrence Barwick <barwick@gmail.com>
Cc: pgsql-hackers@postgresql.org
Date: 2025-01-11T00:27:12Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Fix PDF doc build.

  2. Add SQL function CASEFOLD().

  3. Add support for Unicode case folding.

Attachments

On Wed, 2025-01-08 at 15:19 -0800, Jeff Davis wrote:
> 3. Allow CASEFOLD() to break the normal form of the input string. The
> problem here is that the user may be surprised that the output is not
> normalized even when all of their data is normalized. It's not clear
> to
> me whether it still works for caseless matching -- it might if the
> string is in a consistent form, even if not normalized.

Looking at the Unicode standard again, it distinguishes between
"default caseless matching" and "canonical caseless matching". The
latter accounts for a few nuances that the former does not. See Unicode
16.0 section 3.13.4 D144 & D145. Using Default Caseless Matching
simplifies things quite a bit.

We could argue that it would be nice to have canonical caseless
matching, but that seems to be going above and beyond what Unicode
suggests. And normalization is expensive -- if we combine case folding
and normalization, there's no way for the user to avoid the cost. So
I'm changing my answer to #3, and we just document that it does not
preserve normalization. I believe this means that Peter and I are now
in agreement[1], though I'm not sure if his reasoning is the same.

New patch series attached.

Regards,
	Jeff Davis

[1] 
https://www.postgresql.org/message-id/8c384b0d-00f2-4515-8e60-ff7d0d4c093a%40eisentraut.org