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 |
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 |