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: Noah Misch <noah@leadboat.com>, Tom Lane <tgl@sss.pgh.pa.us>
Cc: Jeff Davis <pgsql@j-davis.com>, Peter Eisentraut <peter@eisentraut.org>, Daniel Verite <daniel@manitou-mail.org>, Robert Haas <robertmhaas@gmail.com>, Jeremy Schneider <schneider@ardentperf.com>, pgsql-hackers@postgresql.org
Date: 2024-07-09T08:00:24Z
Lists: pgsql-hackers 
On Mon, 2024-07-08 at 18:05 -0700, Noah Misch wrote:
> > I do not think it is realistic to define "IMMUTABLE" as meaning that
> > the function will never change behavior until the heat death of the
> > universe.  As a counterexample, we've not worried about applying
> > bug fixes or algorithm improvements that change the behavior of
> > "immutable" numeric computations.
> 
> True.  There's a continuum from "releases can change any IMMUTABLE function"
> to "index integrity always wins, even if a function is as wrong as 1+1=3".
> I'm less concerned about the recent "Incorrect results from numeric round"
> thread, even though it's proposing to back-patch.  I'm thinking about these
> aggravating factors for $SUBJECT:
> 
> - $SUBJECT is planning an annual cadence of this kind of change.
> 
> - We already have ICU providing collation support for the same functions.
>   Unlike $SUBJECT, ICU integration gives packagers control over when to accept
>   corruption at pg_upgrade time.
> 
> - SQL Server, DB2 and Oracle do their Unicode updates in a non-corrupting way.
>   (See Jeremy Schneider's reply concerning DB2 and Oracle.)
> 
> - lower() and regexp are more popular in index expressions than
>   high-digit-count numeric calculations.

My personal exprience is that very few users are aware of or care about
the strict accuracy of the collation sort order and other locale aspects.
But they care a lot about index corruption.

So I'd argue that we should not have any breaking changes at all, even in
cases where the provider is clearly wrong.

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.