Re: Change initdb default to the builtin collation provider - Mailing list pgsql-hackers

From Laurenz Albe
Subject Re: Change initdb default to the builtin collation provider
Date
Msg-id f9ec020747b0ff4760739cf93037273a40ec6edc.camel@cybertec.at
Whole thread Raw
In response to Re: Change initdb default to the builtin collation provider  (Jeff Davis <pgsql@j-davis.com>)
List 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



pgsql-hackers by date:

Previous
From: Kirill Reshke
Date:
Subject: Re: SQL:2011 Application Time Update & Delete
Next
From: Mark Woodward
Date:
Subject: Re: Potential security risk associated with function call