On Thu, 2025-07-17 at 11:59 -0700, Jeff Davis wrote:
> On Thu, 2025-07-17 at 08:30 +0200, Laurenz Albe wrote:
> > I wasn't aware how Oracle handles case mapping, but it seems you
> > are right:
>
> How does it handle UPPER('ß')? If the result is 'ß', that means it's
> similar to the builtin C.UTF-
On Thu, 2025-07-17 at 08:30 +0200, Laurenz Albe wrote:
> I wasn't aware how Oracle handles case mapping, but it seems you
> are right:
How does it handle UPPER('ß')? If the result is 'ß', that means it's
similar to the builtin C.UTF-8. If the result is 'SS', that means it's
similar to PG_UNICODE_F
On Wed, 2025-07-16 at 09:46 -0700, Jeff Davis wrote:
> On Wed, 2025-07-16 at 08:29 +0200, Laurenz Albe wrote:
> > I have a radical proposal: Rather than having "initdb" default to
> > whatever locale is in the environment, make it default the the
> > builtin provider and the C collation. Wherever
On Wed, 2025-07-16 at 08:29 +0200, Laurenz Albe wrote:
> I have a radical proposal: Rather than having "initdb" default to
> whatever locale is in the environment, make it default the the
> builtin
> provider and the C collation. Wherever people need a natural
> language
> collation, they can say
On Tue, 2025-07-15 at 17:34 -0700, Jeff Davis wrote:
> Currently, users who don't make any explicit choice about collation end
> up with primary key indexes that use a libc natural language collation.
> This default is exactly wrong: [...]
>
> So I think we need to do something. That could be bette
