Re: Change initdb default to the builtin collation provider
| От | Jeff Davis |
|---|---|
| Тема | Re: Change initdb default to the builtin collation provider |
| Дата | |
| Msg-id | deb797b6766db4fd992454c28d36ba227451493e.camel@j-davis.com обсуждение |
| Ответ на | Re: Change initdb default to the builtin collation provider (Laurenz Albe <laurenz.albe@cybertec.at>) |
| Список | 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
В списке pgsql-hackers по дате отправления: