Horton

Re: Built-in CTYPE provider

Peter Eisentraut <peter@eisentraut.org>

View thread View on postgr.es
From: Peter Eisentraut <peter@eisentraut.org>
To: Jeff Davis <pgsql@j-davis.com>, Daniel Verite <daniel@manitou-mail.org>
Cc: Robert Haas <robertmhaas@gmail.com>, Jeremy Schneider <schneider@ardentperf.com>, pgsql-hackers@postgresql.org
Date: 2024-03-26T07:14:46Z
Lists: pgsql-hackers 
On 25.03.24 18:52, Jeff Davis wrote:
> OK, I'll propose a "title" or "titlecase" function for 18, along with
> "casefold" (which I was already planning to propose).

(Yay, casefold will be useful.)

> What do you think about UPPER/LOWER and full case mapping? Should there
> be extra arguments for full vs simple case mapping, or should it come
> from the collation?
> 
> It makes sense that the "dotted vs dotless i" behavior comes from the
> collation because that depends on locale. But full-vs-simple case
> mapping is not really a locale question. For instance:
> 
>     select lower('0Σ' collate "en-US-x-icu") AS lower_sigma,
>            lower('ΑΣ' collate "en-US-x-icu") AS lower_final_sigma,
>            upper('ß' collate "en-US-x-icu") AS upper_eszett;
>      lower_sigma | lower_final_sigma | upper_eszett
>     -------------+-------------------+--------------
>      0σ          | ας                | SS
> 
> produces the same results for any ICU collation.

I think of a collation describing what language a text is in.  So it 
makes sense that "dotless i" depends on the locale/collation.

Full vs. simple case mapping is more of a legacy compatibility question, 
in my mind.  There is some expectation/precedent that C.UTF-8 uses 
simple case mapping, but beyond that, I don't see a reason why someone 
would want to explicitly opt for simple case mapping, other than if they 
need length preservation or something, but if they need that, then they 
are going to be in a world of pain in Unicode anyway.

> There's also another reason to consider it an argument rather than a
> collation property, which is that it might be dependent on some other
> field in a row. I could imagine someone wanting to do:
> 
>     SELECT
>       UPPER(some_field,
>             full => true,
>             dotless_i => CASE other_field WHEN ...)
>     FROM ...

Can you index this usefully?  It would only work if the user query 
matches exactly this pattern?

> That makes sense for a function in the target list, because different
> customers might be from different locales and therefore want different
> treatment of the dotted-vs-dotless-i.

There is also the concept of a session collation, which we haven't 
implemented, but it would address this kind of use.  But there again the 
problem is indexing.  But maybe indexing isn't as important for case 
conversion as it is for sorting.

Commits

  1. Support PG_UNICODE_FAST locale in the builtin collation provider.

  2. Support Unicode full case mapping and conversion.

  3. Fix test failures when language environment is not UTF-8.

  4. Add unicode_strtitle() for Unicode Default Case Conversion.

  5. Use version for builtin collations.

  6. Fix convert_case(), introduced in 5c40364dd6.

  7. Inline basic UTF-8 functions.

  8. Support C.UTF-8 locale in the new builtin collation provider.

  9. Fix another warning, introduced by 846311051e.

  10. Address more review comments on commit 2d819a08a1.

  11. Fix unreachable code warning from commit 2d819a08a1.

  12. Introduce "builtin" collation provider.

  13. Catalog changes preparing for builtin collation provider.

  14. Unicode case mapping tables and functions.

  15. Add Unicode property tables.

  16. Documentation update for Standard Collations.

  17. Cleanup for unicode-update build target and test.

  18. Shrink Unicode category table.

  19. Make some error strings more generic

  20. pg_upgrade: copy locale and encoding information to new cluster.

  21. Update Unicode data to Unicode 15.0.0

  22. Create a new type category for "internal use" types.