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
On Fri, 2025-10-17 at 15:02 -0700, Jeff Davis wrote:
> 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 th
---
Summary
---
The libc collation provider is a bad default[1]. The builtin collation
provider is a good default, so let's use that.
--
Motivation
--
The initdb default is what we choose for new postgres instances when
we have little information about the user's collatio
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 her
On 11.10.25 02:48, Jeff Davis wrote:
The builtin provider uses code point order, i.e. memcmp(), so the
final result display order is less human-friendly. For instance, 'Z'
comes before 'a'.
That problem is annoying, but*much* easier to fix than the other
factors. The user might add a COLLATE cla
