Content-Type: text/plain; charset="iso-8859-15"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
From: "Daniel Verite" <daniel@manitou-mail.org>
Subject: Re: LOCALE C.UTF-8 on EDB Windows v17 server
To: "Dominique Devienne" <ddevienne@gmail.com>
Cc: "Laurenz Albe" <laurenz.albe@cybertec.at>,pgsql-general@postgresql.org
In-Reply-To: <CAFCRh--J-Ra-Y73utj9SN4koJnucAH9+7eOY4Ya-av1wtv3pqg@mail.gmail.com>
Date: Thu, 05 Jun 2025 17:01:52 +0200
Message-Id: <5da10da1-c842-43fa-acf8-98a1fe8ddcfd@manitou-mail.org>
Archived-At: <https://www.postgresql.org/message-id/5da10da1-c842-43fa-acf8-98a1fe8ddcfd%40manitou-mail.org>
Precedence: bulk

	Dominique Devienne wrote:

> >  locale 'C.UTF-8' or lc_collate 'C.UTF-8' lc_ctype 'C.UTF-8'
> > cannot work on Windows because Windows does not have a locale
> > named C.UTF-8, whereas a Linux system does (well at least recent
> > Linuxes. Some old Linuxes don't).
>=20
> But isn't the point of the new-in-v17 builtin provider is to be system
> independent???

Yes, definitely.

But suppose your database has an extension that calls local-dependent
code, such as strxfrm() [1] for instance.

The linked MSVC doc says:

 "The transformation is made using the locale's LC_COLLATE category
 setting. For more information on LC_COLLATE, see setlocale. strxfrm
 uses the current locale for its locale-dependent behavior"

But what will be the value in LC_COLLATE when this extension code
is running in a database using the builtin provider?
It's the value found in pg_database.datcollate that was specified
when creating the database with the lc_collate or locale option.

The builtin provider routines are used for code inside Postgres
core, but code outside its perimeter can still call libc functions
that depend on lc_collate and lc_ctype.


[1]
https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/strxfrm-w=
csxfrm-strxfrm-l-wcsxfrm-l?view=3Dmsvc-170

Best regards,
--=20
Daniel V=E9rit=E9=20
https://postgresql.verite.pro/