public inbox for pgsql-general@postgresql.org  

help / color / mirror / Atom feed

Re: Choosing default collation/ctype
2+ messages / 2 participants
[nested] [flat]

* Re: Choosing default collation/ctype
@ 2026-05-05 11:31 Laurenz Albe <laurenz.albe@cybertec.at>
  2026-05-05 18:28 ` Re: Choosing default collation/ctype Daniel Verite <daniel@manitou-mail.org>
  0 siblings, 1 reply; 2+ messages in thread

From: Laurenz Albe @ 2026-05-05 11:31 UTC (permalink / raw)
  To: Daniel Verite <daniel@manitou-mail.org>; +Cc: Ron Johnson <ronljohnsonjr@gmail.com>; pgsql-general@lists.postgresql.org

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






^ permalink  raw  reply  [nested|flat] 2+ messages in thread

* Re: Choosing default collation/ctype
  2026-05-05 11:31 Re: Choosing default collation/ctype Laurenz Albe <laurenz.albe@cybertec.at>
@ 2026-05-05 18:28 ` Daniel Verite <daniel@manitou-mail.org>
  0 siblings, 0 replies; 2+ messages in thread

From: Daniel Verite @ 2026-05-05 18:28 UTC (permalink / raw)
  To: Laurenz Albe <laurenz.albe@cybertec.at>; +Cc: Ron Johnson <ronljohnsonjr@gmail.com>; pgsql-general@lists.postgresql.org

	Laurenz Albe wrote:

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

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,
-- 
Daniel Vérité 
https://postgresql.verite.pro/






^ permalink  raw  reply  [nested|flat] 2+ messages in thread

end of thread, other threads:[~2026-05-05 18:28 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2026-05-05 11:31 Re: Choosing default collation/ctype Laurenz Albe <laurenz.albe@cybertec.at>
2026-05-05 18:28 ` Daniel Verite <daniel@manitou-mail.org>

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox