Re: Collation and primary keys

From: "Daniel Verite" <daniel(at)manitou-mail(dot)org>
To: "Jeff Davis" <pgsql(at)j-davis(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Collation and primary keys
Date: 2025-07-23 11:53:52
Message-ID: 918773d0-886b-4ce0-8b74-ae23496ad3ef@manitou-mail.org
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Jeff Davis wrote:

> * The libc C.UTF-8 locale was a reasonable default (though not a
> natural language collation). But now that we have C.UTF-8 available
> from the builtin provider, then we should encourage that instead of
> relying on the slower, platform-specific libc implementation.

Yes. In particular, we should encourage the ecosystem to support
the new collation features so that they're widely available to
end users.

Anecdotically I was looking this week at upgrading instances to
v17 with the builtin C.UTF-8 locale.

They happen to be hosted by RDS, and RDS appears not to offer
the builtin provider at instance creation (nor ICU, even though
initdb with ICU is possible since v15).
The templates being restrained to libc, the database creations
should then use template0, locale_provider=builtin,
builtin_locale=...
But in my case, database creations have to be done by TerraForm.
And as it turns out, TF's Postgres resource [1] also hasn't been
updated to allow for non-libc databases (only lc_collate and
lc_ctype can be set).

Conclusion for that upgrade: that will be v17 with libc collations :(

[1]
https://registry.terraform.io/providers/cyrilgdn/postgresql/latest/docs/resources/postgresql_database

Best regards,
--
Daniel Vérité
https://postgresql.verite.pro/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ajin Cherian 2025-07-23 11:58:39 Re: 024_add_drop_pub.pl might fail due to deadlock
Previous Message Daniel Westermann (DWE) 2025-07-23 11:30:54 Re: Postgres keep alive configuration