Horton

Re: Built-in CTYPE provider

Jeff Davis <pgsql@j-davis.com>

View thread View on postgr.es
From: Jeff Davis <pgsql@j-davis.com>
To: Noah Misch <noah@leadboat.com>, Tom Lane <tgl@sss.pgh.pa.us>
Cc: Laurenz Albe <laurenz.albe@cybertec.at>, Peter Eisentraut <peter@eisentraut.org>, Daniel Verite <daniel@manitou-mail.org>, Jeremy Schneider <schneider@ardentperf.com>, Robert Haas <robertmhaas@gmail.com>, pgsql-hackers@postgresql.org
Date: 2024-07-19T15:50:41Z
Lists: pgsql-hackers 
On Thu, 2024-07-18 at 16:39 -0700, Noah Misch wrote:
> I'm with a different kind of packager.  I don't tolerate index scans
> returning
> wrong answers.

I doubt that. We've all been tolerating the risk of index scans
returning wrong results in some cases.

Consider:

a. Some user creates an expression index on NORMALIZE(); vs.
b. Some user chooses the builtin "C.UTF-8" locale and creates a partial
index with a predicate like "string ~ '[[:alpha:]]'" (or an expression
index on LOWER())

Both cases create a risk if we update Unicode in some future version.
Why are you unconcerned about case (a), but highly concerned about case
(b)?

Neither seem to be a pressing problem because updating Unicode is our
choice, so we have time to reach a compromise.

> [1] Daniel Verite said packagers could patch src/Makefile.global.in
> and run
> "make -C src/common/unicode update-unicode".  Editing
> src/Makefile.global.in
> is modifying PostgreSQL, not configuring a packager-facing option.

Then go to the other thread[1] and propose that it be exposed as a
packager-facing option along with any proposed Unicode update. There
are other potential compromises possible, so I don't think this 17
subthread is the right place to discuss it, but it strikes me as a
reasonable proposal.

I sincerely think you are overcomplicating matters with version 17
procedural motions. Let the community process play out in version 18
like normal, because there's no actual problem now, I see no reason
your objections would be taken less seriously later.

Regards,
	Jeff Davis

[1] 
https://www.postgresql.org/message-id/d75d2d0d1d2bd45b2c332c47e3e0a67f0640b49c.camel%40j-davis.com

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.