Message-ID: <2692039df6b0cac20c5e488fa0209e8958c5fedb.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: Mon, 12 Feb 2024 18:01:29 -0800
In-Reply-To: <612987b5-38fa-44c6-8b78-c0be5a177a70@eisentraut.org>
References: <6f3e94c0-f174-4380-9b69-072f8a838881@manitou-mail.org>
	 <12e4f6a78403b33c303c20e44976f891d879be09.camel@j-davis.com>
	 <612987b5-38fa-44c6-8b78-c0be5a177a70@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/2692039df6b0cac20c5e488fa0209e8958c5fedb.camel%40j-davis.com>
Precedence: bulk

On Wed, 2024-02-07 at 10:53 +0100, Peter Eisentraut wrote:
> Various comments are updated to include the term "character class".=C2=A0
> I=20
> don't recognize that as an official Unicode term.=C2=A0 There are
> categories=20
> and properties.=C2=A0 Let's check this.

It's based on
https://www.unicode.org/reports/tr18/#Compatibility_Properties

so I suppose the right name is "properties".

> Is it potentially confusing that only some pg_u_prop_* have a posix
> variant?=C2=A0 Would it be better for a consistent interface to have a
> "posix" argument for each and just ignore it if not used?=C2=A0 Not sure.

I thought about it but didn't see a clear advantage one way or another.

> About this initdb --builtin-locale option and analogous options=20
> elsewhere:=C2=A0 Maybe we should flip this around and provide a --libc-
> locale=20
> option, and have all the other providers just use the --locale
> option.=20
> This would be more consistent with the fact that it's libc that is=20
> special in this context.

Would --libc-locale affect all the environment variables or just
LC_CTYPE/LC_COLLATE? How do we avoid breakage?

I like the general direction here but we might need to phase in the
option or come up with a new name. Suggestions welcome.

> Do we even need the "C" locale?=C2=A0 We have established that "C.UTF-8"
> is=20
> useful, but if that is easily available, who would need "C"?

I don't think we should encourage its use generally but I also don't
think it will disappear any time soon. Some people will want it on
simplicity grounds. I hope fewer people will use "C" when we have a
better builtin option.

> Some changes in this patch appear to be just straight renamings, like
> in
> src/backend/utils/init/postinit.c and=20
> src/bin/pg_upgrade/t/002_pg_upgrade.pl.=C2=A0 Maybe those should be put
> into=20
> the previous patch instead.
>=20
> On the collation naming: My expectation would have been that the=20
> "C.UTF-8" locale would be exposed as the UCS_BASIC collation.

I'd like that. We have to sort out a couple things first, though:

1. The SQL spec mentions the capitalization of "=C3=9F" as "SS"
specifically. Should UCS_BASIC use the unconditional mappings in
SpecialCasing.txt? I already have some code to do that (not posted
yet).

2. Should UCS_BASIC use the "POSIX" or "Standard" variant of regex
properties? (The main difference seems to be whether symbols get
treated as punctuation or not.)

3. What do we do about potential breakage for existing users of
UCS_BASIC who might be expecting C-like behavior?

Regards,
	Jeff Davis