From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | Peter Eisentraut <peter(at)eisentraut(dot)org>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Change initdb default to the builtin collation provider |
Date: | 2025-10-17 22:02:16 |
Message-ID: | aeb851257920a4f79b7a49fc9e1b114f36235296.camel@j-davis.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, 2025-10-17 at 17:23 +0200, Peter Eisentraut wrote:
> I remain violently opposed to this idea. 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 assume that you favor alternative 3 listed here[1], which is to use
ICU "und" as the default. Is that correct? Or do you prefer to get the
locale from the environment at initdb time?
One thing you may not have considered is that if the provider is
builtin, a lot more users are likely to learn about and use ICU,
because they will see an unfriendly display order and try to figure out
why. Then they'll be more prepared for upgrades and more likely to see
and respond to a version mismatch.
> I don't understand. We have a versioning system for ICU collations?
> Does it not work?
I have 27 versions of ICU installed by compiling them from source, and
I compile Postgres in my sleep, so it's fine for me.
But for the default user, who's never really considered collation until
after they are already in trouble, having inconsistent primary keys all
over the place is not a great experience. ICU is certainly better than
libc, but I still think people should approach it with non-zero
knowledge.
Regards,
Jeff Davis
[1]
https://www.postgresql.org/message-id/3e84e861362e971cf8c7d5e4770207d0235947e1.camel@j-davis.com
From | Date | Subject | |
---|---|---|---|
Next Message | Justin Kwan | 2025-10-17 22:08:00 | Re: Making pg_rewind faster |
Previous Message | Tom Lane | 2025-10-17 21:51:44 | Re: abi-compliance-check failure due to recent changes to pg_{clear,restore}_{attribute,relation}_stats() |