Horton

Re: Built-in CTYPE provider

Laurenz Albe <laurenz.albe@cybertec.at>

View thread View on postgr.es
From: Laurenz Albe <laurenz.albe@cybertec.at>
To: Tom Lane <tgl@sss.pgh.pa.us>, Jeff Davis <pgsql@j-davis.com>
Cc: Noah Misch <noah@leadboat.com>, 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-19T07:44:21Z
Lists: pgsql-hackers 
On Thu, 2024-07-18 at 13:03 -0400, Tom Lane wrote:
> In the second place, I cannot understand why pg_c_utf8 is being
> held to a mutability standard that we have never applied to any
> other locale-related functionality --- and indeed could not do
> so, since in most cases that functionality has been buried in
> libraries we don't control.

I believe that we should hold it to a higher standard *precisely
because* the previous way that we handled mutability in locale-related
functionality was a problem.

> It seems to me to be already a
> great step forward that with pg_c_utf8, at least we can guarantee
> that the behavior won't change without us knowing about it.

+1

But the greatness of the step depends on our readiness to be careful
with such changes.

> Noah's desire to revert the feature makes the mutability situation
> strictly worse, because people will have to continue to rely on
> OS-provided functionality that can change at any time.

I think everybody agrees that we don't want to expose users to data
corruption after an upgrade.

It understand Noah to take the position that anything less than
strict immutability would be worse than the current state, because
currently a packager can choose to keep shipping the same old
version of libicu and avoid the problem completely.

I don't buy that.  First, the only binary distribution I have heard
of that does that is EDB's Windows installer.  Both the RPM and
Debian packages don't.

And until PostgreSQL defaults to using ICU, most people will use
C library collations, and a packager cannot choose not to upgrade
the C library.

I believe the built-in CTYPE provider is a good thing and a step
forward.  But to make it a big step forward, we should be extremely
careful with any changes in major releases that might require
rebuilding indexes.
This is where I side with Noah.

Yours,
Laurenz Albe

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.