Message-ID: <69f832595838e40c1b071a5e750665190ba301bf.camel@j-davis.com>
Subject: Re: Built-in CTYPE provider
From: Jeff Davis <pgsql@j-davis.com>
To: Peter Eisentraut <peter@eisentraut.org>, Daniel Verite
	 <daniel@manitou-mail.org>
Cc: Robert Haas <robertmhaas@gmail.com>, Jeremy Schneider
	 <schneider@ardentperf.com>, pgsql-hackers@postgresql.org
Date: Fri, 22 Mar 2024 10:26:10 -0700
In-Reply-To: <49f18979-bef5-4cf0-bf3d-8a5ed323f470@eisentraut.org>
References: <6f3e94c0-f174-4380-9b69-072f8a838881@manitou-mail.org>
	 <12e4f6a78403b33c303c20e44976f891d879be09.camel@j-davis.com>
	 <612987b5-38fa-44c6-8b78-c0be5a177a70@eisentraut.org>
	 <2692039df6b0cac20c5e488fa0209e8958c5fedb.camel@j-davis.com>
	 <27bb0e52-801d-4f73-a0a4-02cfdd4a9ada@eisentraut.org>
	 <4a69d067374d2f6bfb66f5bfb2ab9a020493d49f.camel@j-davis.com>
	 <3bc653b5d562ae9e2838b11cb696816c328a489a.camel@j-davis.com>
	 <163f4e2190cdf67f67016044e503c5004547e5a9.camel@j-davis.com>
	 <6bdb98e68b2b05aa71f7f934e227738eac84ecee.camel@j-davis.com>
	 <19b34a70-f5cf-4faf-88dc-917db44ed48d@eisentraut.org>
	 <846a7e1fa2024918b58ff7583523a2f3de9a11b4.camel@j-davis.com>
	 <3117d30aa911b408b90420f4f280fa0c3b5851be.camel@j-davis.com>
	 <4135cf11-206d-40ed-96c0-9363c1232379@eisentraut.org>
	 <7451f81ba0cb512222ab759de8ca1cffe44e9acb.camel@j-davis.com>
	 <1f309153-8198-4efa-86dd-8c304ec0040c@eisentraut.org>
	 <a21b515000f121244db2a5570d4292d19df23379.camel@j-davis.com>
	 <49f18979-bef5-4cf0-bf3d-8a5ed323f470@eisentraut.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.44.4-0ubuntu2 
MIME-Version: 1.0
Archived-At: <https://www.postgresql.org/message-id/69f832595838e40c1b071a5e750665190ba301bf.camel%40j-davis.com>
Precedence: bulk

On Fri, 2024-03-22 at 15:51 +0100, Peter Eisentraut wrote:
> I think this might be too big of a compatibility break.=C2=A0 So far,=20
> initcap('123abc') has always returned '123abc'.=C2=A0 If the new collatio=
n
> returns '123Abc' now, then that's quite a change.=C2=A0 These are not som=
e
> 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?=C2=A0 Maybe we could
> have=20
> the builtin provider understand some of that, too.

https://unicode-org.github.io/icu-docs/apidoc/dev/icu4c/stringoptions_8h.ht=
ml#a4975f537b9960f0330b233061ef0608d
https://unicode-org.github.io/icu-docs/apidoc/dev/icu4c/stringoptions_8h.ht=
ml#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.

Regards,
	Jeff Davis