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>, Laurenz Albe <laurenz.albe@cybertec.at>
Cc: Peter Eisentraut <peter@eisentraut.org>, Daniel Verite <daniel@manitou-mail.org>, Jeremy Schneider <schneider@ardentperf.com>, Tom Lane <tgl@sss.pgh.pa.us>, Robert Haas <robertmhaas@gmail.com>, pgsql-hackers@postgresql.org
Date: 2024-07-18T16:52:44Z
Lists: pgsql-hackers 
On Thu, 2024-07-18 at 07:00 -0700, Noah Misch wrote:
> Given all the messages on this thread, if the feature remains in
> PostgreSQL, I
> advise you to be ready to tolerate PostgreSQL "routinely updating the
> built-in
> provider to adopt any changes that Unicode makes".

You mean messages from me, like:

  * "I have no intention force a Unicode update" [1]
  * "While nothing needs to be changed for 17, I agree that we may need
to be careful in future releases not to break things." [2]
  * "...you are right that we may need to freeze Unicode updates or be
more precise about versioning..." [2]
  * "If you are proposing that Unicode updates should not be performed
if they affect the results of any IMMUTABLE function...I am neither
endorsing nor opposing..." [3]

?

The only source I can imagine for your concern -- please correct me if
I'm wrong -- is that I declined to make a preemptive version 18 promise
deep in this version 17 Open Item subthread. But I have good reasons.
First, if we promise not to update Unicode, that would also affect
NORMALIZE(), so for the sake of transparency we need a top-level
discussion. Second, an Open Item should be tightly scoped to what
actually needs to happen in version 17 before release. And thirdly,
such a promise would artificially limit the range of possible outcomes,
which may include various compromises that are not 17 material.

I'm perplexed as to why you don't engage in the version 18 policy
discussion.

>   Maybe someone will change
> something in v18 so it's not like that, but don't count on it.

That's backwards. If nothing happens in v18, then there will be no
breaking Unicode change. It takes an active step by a committer to
update Unicode.

Regards,
	Jeff Davis

[1] 
https://www.postgresql.org/message-id/5edb38923b0b23eb643f61807ef772a237ab92cf.camel%40j-davis.com
[2]
https://www.postgresql.org/message-id/db496682c6656ac64433f05f8821e561bbf4d105.camel@j-davis.com
[3]
https://www.postgresql.org/message-id/1d178eb1bbd61da1bcfe4a11d6545e9cdcede1d1.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.