Content-Type: text/plain; charset="iso-8859-15"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: LOCALE C.UTF-8 on EDB Windows v17 server
From: "Daniel Verite" <daniel@manitou-mail.org>
To: "Dominique Devienne" <ddevienne@gmail.com>
Cc: "Laurenz Albe" <laurenz.albe@cybertec.at>,pgsql-general@postgresql.org
In-Reply-To: <CAFCRh--iJ4MT2exvXnvRPum+7su3Jn9qmnBQqxWsAtyEyEo83A@mail.gmail.com>
Date: Thu, 05 Jun 2025 14:40:08 +0200
Message-Id: <d57d35d0-9d27-4be7-aad9-b139a18b990d@manitou-mail.org>
Archived-At: <https://www.postgresql.org/message-id/d57d35d0-9d27-4be7-aad9-b139a18b990d%40manitou-mail.org>
Precedence: bulk

	Dominique Devienne wrote:

> On Linux, no error unlike on Windows (still inconsistent there IMHO),
> but the result is slightly different for datcollate and datctype (C vs
> en_US),
> while the same for datlocprovider and datlocale, what I looked at.
>=20
> Thus I kinda persist that there *is* a portability issue here.

"datcollate" and "datctype" refer to operating system locale names.

 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).

What you are seeing is the effect of OS locales not being portable
across systems. That's confusing but not a Postgres bug.


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