Message-ID: <0f8d5290eb4bcab682e5fb8030ef3e24f6ed60f2.camel@j-davis.com>
Subject: Re: Built-in CTYPE provider
From: Jeff Davis <pgsql@j-davis.com>
To: Daniel Verite <daniel@manitou-mail.org>
Cc: Robert Haas <robertmhaas@gmail.com>, Jeremy Schneider
	 <schneider@ardentperf.com>, pgsql-hackers@postgresql.org
Date: Thu, 11 Jan 2024 11:05:36 -0800
In-Reply-To: <6f3e94c0-f174-4380-9b69-072f8a838881@manitou-mail.org>
References: <6f3e94c0-f174-4380-9b69-072f8a838881@manitou-mail.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/0f8d5290eb4bcab682e5fb8030ef3e24f6ed60f2.camel%40j-davis.com>
Precedence: bulk

On Wed, 2024-01-10 at 23:56 +0100, Daniel Verite wrote:
> $ bin/initdb --locale=3DC.UTF-8 --locale-provider=3Dbuiltin -D/tmp/pgdata
> =C2=A0
> =C2=A0 The database cluster will be initialized with this locale
> configuration:
> =C2=A0=C2=A0=C2=A0 default collation provider:=C2=A0 builtin
> =C2=A0=C2=A0=C2=A0 default collation locale:=C2=A0=C2=A0=C2=A0 C.UTF-8
> =C2=A0=C2=A0=C2=A0 LC_COLLATE:=C2=A0 C.UTF-8
> =C2=A0=C2=A0=C2=A0 LC_CTYPE:=C2=A0=C2=A0=C2=A0 C.UTF-8
> =C2=A0=C2=A0=C2=A0 LC_MESSAGES: C.UTF-8
> =C2=A0=C2=A0=C2=A0 LC_MONETARY: C.UTF-8
> =C2=A0=C2=A0=C2=A0 LC_NUMERIC:=C2=A0 C.UTF-8
> =C2=A0=C2=A0=C2=A0 LC_TIME:=C2=A0=C2=A0=C2=A0=C2=A0 C.UTF-8
> =C2=A0 The default database encoding has accordingly been set to "UTF8".
> =C2=A0 The default text search configuration will be set to "english".
>=20
> This is from an environment where LANG=3Dfr_FR.UTF-8
>=20
> I would expect all LC_* variables to be fr_FR.UTF-8, and the default
> text search configuration to be "french".

You can get the behavior you want by doing:

  initdb --builtin-locale=3DC.UTF-8 --locale-provider=3Dbuiltin \
    -D/tmp/pgdata

where "--builtin-locale" is analogous to "--icu-locale".

It looks like I forgot to document the new initdb option, which seems
to be the source of the confusion. Sorry, I'll fix that in the next
patch set. (See examples in the initdb tests.)

I think this answers some of your follow-up questions as well.

> A related comment is about naming the builtin locale C.UTF-8, the
> same
> name as in libc. On one hand this is semantically sound, but on the
> other hand, it's likely to confuse people. What about using
> completely
> different names, like "pg_unicode" or something else prefixed by
> "pg_"
> both for the locale name and the collation name (currently
> C.UTF-8/c_utf8)?

I'm flexible on naming, but here are my thoughts:

* A "pg_" prefix makes sense.

* If we named it something like "pg_unicode" someone might expect it to
sort using the root collation.

* The locale name "C.UTF-8" is nice because it implies things about
both the collation and the character behavior. It's also nice because
on at least some platforms, the behavior is almost identical to the
libc locale of the same name.

* UCS_BASIC might be a good name, because it also seems to carry the
right meanings, but that name is already taken.

* We also might to support variations, such as full case mapping (which
uppercases "=C3=9F" to "SS", as the SQL standard requires), or perhaps the
"standard" flavor of regexes (which don't count all symbols as
punctuation). Leaving some room to name those variations would be a
good idea.

Regards,
	Jeff Davis