Message-ID: <7a6954c2dfe3f224b4c45aa59f7fb6e951ce93b0.camel@cybertec.at>
Subject: Re: Choosing default collation/ctype
From: Laurenz Albe <laurenz.albe@cybertec.at>
To: Daniel Verite <daniel@manitou-mail.org>
Cc: Ron Johnson <ronljohnsonjr@gmail.com>, pgsql-general@lists.postgresql.org
Date: Tue, 05 May 2026 13:31:00 +0200
In-Reply-To: <f7b3c538-8e78-47f4-82f1-2e54e8da2f0b@manitou-mail.org>
References: <f7b3c538-8e78-47f4-82f1-2e54e8da2f0b@manitou-mail.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.58.3 (3.58.3-1.fc43) 
MIME-Version: 1.0
Archived-At: <https://www.postgresql.org/message-id/7a6954c2dfe3f224b4c45aa59f7fb6e951ce93b0.camel%40cybertec.at>
Precedence: bulk

On Tue, 2026-05-05 at 13:16 +0200, Daniel Verite wrote:
> Laurenz Albe wrote:
>=20
> > > So if you target Postgres 17+, C.UTF-8 from the builtin provider is
> > > a better choice for UTF-8 databases than "C" .
> >=20
> > Yes, "builtin" and the "C" collation is the best default value.
>=20
> But my point was that, no, it's not.
> Let's show a concrete example with Postgres 18:
>=20
> [...]
>
> It is not the correct uppercasing.

That is true.
But if you are using "C.UTF-8", the semantics of upper() can change
between versions, if Unicode is upgraded.  That bears a residual risk
of OS upgrades breaking indexes on upper(col).

I'd say that the small benefit of better case conversion isn't worth
the risk.  I'd chose "C", and use a natural language collation explicitly
on columns where these things matter.

Yours,
Laurenz Albe