Re: Built-in CTYPE provider - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Built-in CTYPE provider
Date
Msg-id 49f18979-bef5-4cf0-bf3d-8a5ed323f470@eisentraut.org
Whole thread Raw
In response to Re: Built-in CTYPE provider  (Jeff Davis <pgsql@j-davis.com>)
Responses Re: Built-in CTYPE provider
List pgsql-hackers
On 21.03.24 01:13, Jeff Davis wrote:
>> Are there any test cases that illustrate the word boundary changes in
>> patch 0005?  It might be useful to test those against Oracle as well.
> The tests include initcap('123abc') which is '123abc' in the PG_C_UTF8
> collation vs '123Abc' in PG_UNICODE_FAST.
> 
> The reason for the latter behavior is that the Unicode Default Case
> Conversion algorithm for toTitlecase() advances to the next Cased
> character before mapping to titlecase, and digits are not Cased. ICU
> has a configurable adjustment, and defaults in a way that produces
> '123abc'.

I think this might be too big of a compatibility break.  So far, 
initcap('123abc') has always returned '123abc'.  If the new collation 
returns '123Abc' now, then that's quite a change.  These are not some 
obscure Unicode special case characters, after all.

What is the ICU configuration incantation for this?  Maybe we could have 
the builtin provider understand some of that, too.

Or we should create a function separate from initcap.




pgsql-hackers by date:

Previous
From: Nathan Bossart
Date:
Subject: Re: Slow GRANT ROLE on PostgreSQL 16 with thousands of ROLEs
Next
From: Nathan Bossart
Date:
Subject: Re: Slow GRANT ROLE on PostgreSQL 16 with thousands of ROLEs