Re: Change initdb default to the builtin collation provider

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Change initdb default to the builtin collation provider
Date: 2026-03-11 21:43:11
Message-ID: deb797b6766db4fd992454c28d36ba227451493e.camel@j-davis.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, 2026-03-11 at 21:05 +0100, Laurenz Albe wrote:
> The big advantage: if you have only two or three indexes in your
> database that are sorted in a collation other than C, the likelihood
> for index corruption will be way lower.  For example, the unique
> constraint on your part number column that contains values like
> 'XY-1-13*' or '*P1-12_A' (which are pretty likely to be affected by
> the subtle changes in libc collations) will be sorted in the C
> collation, which is just fine for everybody.

Agreed. The collation problems are not because it's used in the handful
of indexes where it's useful; the problems happen when it's used
everywhere.

If a collation version change is detected, and a few indexes need to be
REINDEXed, I think users understand that. But it's pretty difficult to
explain to a user that all text indexes (including primary keys) need
to be reindexed, and that there's no way to keep track of what still
needs to be done.

Regards,
Jeff Davis

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2026-03-11 21:48:08 Re: tid_blockno() and tid_offset() accessor functions
Previous Message Andres Freund 2026-03-11 21:39:04 Re: [PATCH v1] command_tag_format — protocol-level command tag negotiation via _pq_