| From: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
|---|---|
| To: | Daniel Verite <daniel(at)manitou-mail(dot)org> |
| Cc: | Ron Johnson <ronljohnsonjr(at)gmail(dot)com>, pgsql-general(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Choosing default collation/ctype |
| Date: | 2026-05-05 11:31:00 |
| Message-ID: | 7a6954c2dfe3f224b4c45aa59f7fb6e951ce93b0.camel@cybertec.at |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ken Marshall | 2026-05-05 11:38:24 | Re: ODBC SSL connection issue on Solaris with PostgreSQL 18 (OpenSSL 1.0.2) |
| Previous Message | Daniel Verite | 2026-05-05 11:16:14 | Re: Choosing default collation/ctype |