| 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
| 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 |