Re: Built-in CTYPE provider

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