Message-ID: <5a1ecc40539f36cac5b27a62739a45a49785ca54.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: Thu, 14 Mar 2024 13:42:28 -0700
In-Reply-To: <613c120a-5413-4fa7-a501-6590eae558f8@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>
	 <613c120a-5413-4fa7-a501-6590eae558f8@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/5a1ecc40539f36cac5b27a62739a45a49785ca54.camel%40j-davis.com>
Precedence: bulk

On Thu, 2024-03-14 at 15:38 +0100, Peter Eisentraut wrote:
> On 14.03.24 09:08, Jeff Davis wrote:
> > 0001 (the C.UTF-8 locale) is also close...
>=20
> If have tested this against the libc locale C.utf8 that was available
> on=20
> the OS, and the behavior is consistent.

That was the goal, in spirit.

But to clarify: it's not guaranteed that the built-in C.UTF-8 is always
the same as the libc UTF-8, because different implementations do
different things. For instance, I saw significant differences on MacOS.

> I wonder if we should version the builtin locales too.=C2=A0 We might mak=
e
> a=20
> mistake and want to change something sometime?

I'm fine with that, see v25-0004 in the reply to your other mail.

The version only tracks sort order, and all of the builtin locales sort
based on memcmp(). But it's possible there are bugs in the
optimizations around memcmp() (e.g. abbreviated keys, or some future
optimization).

> Tiny comments:
>=20
> * src/bin/scripts/t/020_createdb.pl
>=20
> The two added tests should have different names that tells them apart
> (like the new initdb tests).
>=20
> * src/include/catalog/pg_collation.dat

Done in v25-0002 (in reply to your other mail).

Regards,
	Jeff Davis