Re: Change initdb default to the builtin collation provider

On Thu, 2026-03-12 at 10:04 -0400, Robert Haas wrote:
> So maybe the people who are saying that defaulting to C is fine and
> that making people make an explicit choice if they want something else
> are right. but my personal guess is that we will make a bunch of
> people unhappy.

Defaulting to C will make a bunch of people unhappy, I agree.
However, that is a kind of problem that they will discover early on
during development or testing, and it is easily remedied for those
columns where alphabetical sorting order matters.

But a good number of people are already unhappy because they have
index corruption (today I dealt with another support case).
And the people who are diligent enough to know that they should
reindex after an OS update are unhappy because of the additional
down time.

I maintain that the second kind of unhappiness weighs heavier,
and I find this need to reindex to be one of the most embarrassing
flaws in an otherwise great piece of software.

This is a value judgement, and I may be wrong.

> If even a small fraction of users create a
> database using "C" unintentionally and load a terabyte of data into it
> before realizing that all their text indexes are sorting "wrong", I
> suspect that's not going to be much fun.

Hm. So reindexing a large table after an OS upgrade is acceptable,
but reindexing a large table after a bulk load is not? The problem
you describe could have been avoided with a bit of testing, but the
need to reindex after an OS upgrade sometimes cannot be avoided.

> Obviously, I could be wildly incorrect. Maybe people will just be
> super-happy about faster sorting and life will be great.

I have not experienced sort speed as a frequent problem, and the
life with the C collation won't be all that great. But I believe
that it would be better than a life with index corruption.

Yours,
Laurenz Albe