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>
To: "Laurenz Albe" <laurenz.albe@cybertec.at>
Cc: Ron Johnson <ronljohnsonjr@gmail.com>,
 pgsql-general@lists.postgresql.org
Subject: Re: Choosing default collation/ctype
In-Reply-To: <7a6954c2dfe3f224b4c45aa59f7fb6e951ce93b0.camel@cybertec.at>
Date: Tue, 05 May 2026 20:28:43 +0200
Message-Id: <555d1594-87fd-44ef-be4d-ef001ef5d2e1@manitou-mail.org>
Archived-At: <https://www.postgresql.org/message-id/555d1594-87fd-44ef-be4d-ef001ef5d2e1%40manitou-mail.org>
Precedence: bulk

	Laurenz Albe wrote:

> But if you are using "C.UTF-8", the semantics of upper() can change
> between versions, if Unicode is upgraded.=20

Oh I see. Sure, "C" is not affected by that.

> That bears a residual risk
> of OS upgrades breaking indexes on upper(col).

OS upgrades don't count in the case of the builtin provider, but
major Postgres upgrades, yes.

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

While I understanding the reasoning, I'm of the opposite opinion.
To me the lack of Unicode support in "C" is too annoying to make
it a blanket recommendation as the default locale.


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