Re: Collation and primary keys

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Collation and primary keys
Date: 2025-07-16 16:46:06
Message-ID: cc42b1cb548dbca316e1e30de62c901f078f7216.camel@j-davis.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, 2025-07-16 at 08:29 +0200, Laurenz Albe wrote:
> I have a radical proposal: Rather than having "initdb" default to
> whatever locale is in the environment, make it default the the
> builtin
> provider and the C collation.  Wherever people need a natural
> language
> collation, they can say so explicitly.

You bring up a good sub-point, which is that there are actually three
builtin locales[1]: C, C.UTF-8, and PG_UNICODE_FAST. All three have
exactly the same sorting and equality semantics (memcmp()), and
therefore any of them would solve the problems raised in this thread.

> Not that I want to present Oracle as an example to follow in general,
> but that's how they are doing it, and while I do hear complaints from
> Oracle users, I have yet to hear a complaint about the default binary
> collation.

My understanding was that, while it does binary sort order, it still
does Unicode-aware case mapping.

If so, that would be closer to the C.UTF-8 locale (Unicode Simple Case
Mapping) or the PG_UNICODE_FAST locale (Unicode Full Case Mapping,
which includes multi-character mappings like 'ß' to 'SS').

Note that the SQL standard seems to require Unicode Full Case Mapping.

Regards,
Jeff Davis

[1] https://www.postgresql.org/docs/devel/locale.html#LOCALE-PROVIDERS

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Nathan Bossart 2025-07-16 16:55:48 Re: fix organization wording in psql's \copyright command
Previous Message Peter Geoghegan 2025-07-16 16:39:28 Re: index prefetching