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
(The problem and possible solutions are not specific to primary keys,
but I'm focusing on PKs for the purposes of this email.)
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 wro
