Re: Inconsistent results with libc sorting on Windows

From: Juan José Santamaría Flecha <juanjo(dot)santamaria(at)gmail(dot)com>
To: Noah Misch <noah(at)leadboat(dot)com>
Cc: Peter Geoghegan <pg(at)bowt(dot)ie>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Daniel Verite <daniel(at)manitou-mail(dot)org>, Joe Conway <mail(at)joeconway(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Inconsistent results with libc sorting on Windows
Date: 2023-08-11 09:48:18
Message-ID: CAC+AXB1_6KOxMHGBqiD5Lt9OvYSbWcfHjOW9bmfdaz-Hvyp2VA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Aug 11, 2023 at 7:29 AM Noah Misch <noah(at)leadboat(dot)com> wrote:

>
> The LCMapStringEx() solution is elegant. I do see
>
> https://learn.microsoft.com/en-us/windows/win32/intl/handling-sorting-in-your-applications
> says, "If an application calls the function to create a sort key for a
> string
> containing an Arabic kashida, the function creates no sort key value."
> That's
> aggravating.
>

I think the problem there is that it is just poorly explained.
Take for example the attached program that compares "normal" and "kashida"
'Raħīm' taken from [1], you'll get:

c1 = c2
c2 = c1

meaning that "normal" and "kashida" are the same string. So, probably that
phrase should read something like: "If an application calls the function to
create a sort key for a string containing an Arabic kashida character, the
function will ignore that character and no sort key value will be generated
for it."

[1] https://en.wikipedia.org/wiki/Kashida

Regards,

Juan José Santamaría Flecha

Attachment Content-Type Size
compare_kashida.c text/plain 862 bytes

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Smith 2023-08-11 10:10:35 Re: Adding a LogicalRepWorker type field
Previous Message Amit Kapila 2023-08-11 09:33:44 Re: Adding a LogicalRepWorker type field