On 22.03.24 18:26, Jeff Davis wrote:
> On Fri, 2024-03-22 at 15:51 +0100, Peter Eisentraut wrote:
>> 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.
>
> It's a new collation, so I'm not sure it's a compatibility break. But
> you are right that it is against documentation and expectations for
> INITCAP().
>
>> What is the ICU configuration incantation for this? Maybe we could
>> have
>> the builtin provider understand some of that, too.
>
> https://unicode-org.github.io/icu-docs/apidoc/dev/icu4c/stringoptions_8h.html#a4975f537b9960f0330b233061ef0608d
> https://unicode-org.github.io/icu-docs/apidoc/dev/icu4c/stringoptions_8h.html#afc65fa226cac9b8eeef0e877b8a7744e
>
>> Or we should create a function separate from initcap.
>
> If we create a new function, that also gives us the opportunity to
> accept optional arguments to control the behavior rather than relying
> on collation for every decision.
Right. I thought when you said there is an ICU configuration for it,
that it might be like collation options that you specify in the locale
string. But it appears it is only an internal API setting. So that, in
my mind, reinforces the opinion that we should leave initcap() as is and
make a new function that exposes the new functionality. (This does not
have to be part of this patch set.)