Re: Change initdb default to the builtin collation provider

From: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
To: Jeff Davis <pgsql(at)j-davis(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Change initdb default to the builtin collation provider
Date: 2026-03-10 17:42:06
Message-ID: f9ec020747b0ff4760739cf93037273a40ec6edc.camel@cybertec.at
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, 2025-10-31 at 14:30 -0700, Jeff Davis wrote:
> On Fri, 2025-10-10 at 17:48 -0700, Jeff Davis wrote:
> > -------
> > Summary
> > -------
> >
> > The libc collation provider is a bad default[1]. The builtin
> > collation
> > provider is a good default, so let's use that.
>
> The attached patches implement a more modest proposal which does not
> conflict with Peter's objection about the display order:
>
> 0001: If the encoding is unspecified, and cannot be determined from the
> locale (i.e. the locale is C), then use UTF-8 rather than SQL_ASCII.
>
> 0002: If the provider is unspecified, and the locale is C or C.UTF-8,
> then use the builtin provider.

I think that would be an improvement, but I am still much more in
favor of your original proposal to use the C collation by default.

Peter objected:

> I don't understand how it could be acceptable to just not provide
> a good display order by default and have everyone rewrite their queries.

I consider it acceptable. Oracle does it like that by default.
Yes, Oracle's behavior is not necessarily what we want to emulate, but I
don't remember hearing Oracle users complain about that (and I have
heard them complain about other things).

He also said:

> I don't understand. We have a versioning system for ICU collations?
> Does it not work?

Well, it works in that it alerts you that you may have index corruption.
Good - but a default behavior that excludes the possibility of index
corruption after an OS upgrade would work much better for most users.

Yours,
Laurenz Albe

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Mark Woodward 2026-03-10 17:42:58 Re: Potential security risk associated with function call
Previous Message Kirill Reshke 2026-03-10 17:33:30 Re: SQL:2011 Application Time Update & Delete