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-8KoLDppV0K21rLZc=dR9_hgvzgoYf=g5PszbARKZ9RjQ@mail.gmail.com>
Date: Thu, 05 Jun 2025 22:57:24 +0200
Message-Id: <aded3b3d-4849-4bf4-a072-eecf84f5cd4e@manitou-mail.org>
Archived-At: <https://www.postgresql.org/message-id/aded3b3d-4849-4bf4-a072-eecf84f5cd4e%40manitou-mail.org>
Precedence: bulk

	Dominique Devienne wrote:

> So you're saying datcollate and datctype from pg_database are
> irrelevant to PostgreSQL itself, and only extensions might be affects?

Almost. An exception that still exists in v18, as far as I can see [1],
is the default full text search parser still using libc functions like
iswdigit(), iswpunct(), iswspace()... that depend on LC_CTYPE.=20

So you could see differences between OSes in tsvector contents
in a database with the builtin provider.
Unless using LC_CTYPE=3DC. But then the parsing is suboptimal, since the
parser does not recognize Unicode fancy punctuation signs or spaces as
such.
Personally I would still care to set LC_CTYPE to a reasonable UTF-8 locale
with v17 or v18.

[1]
https://doxygen.postgresql.org/wparser__def_8c.html#a420ea398a8a11db92412a2=
af7bf45e40

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