Re: [PROPOSAL] Skip test citext_utf8 on Windows - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: [PROPOSAL] Skip test citext_utf8 on Windows
Date
Msg-id CA+hUKG+OjLxttqs7ffDR1iLJ+9ReJD5wgJJV79rASmNB6=7ATw@mail.gmail.com
Whole thread Raw
In response to Re: [PROPOSAL] Skip test citext_utf8 on Windows  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: [PROPOSAL] Skip test citext_utf8 on Windows
List pgsql-hackers
On Tue, Mar 12, 2024 at 2:56 PM Andrew Dunstan <andrew@dunslane.net> wrote:
> On 2024-03-11 Mo 04:21, Oleg Tselebrovskiy wrote:
> > Greetings, everyone!
> >
> > While running "installchecks" on databases with UTF-8 encoding the test
> > citext_utf8 fails because of Turkish dotted I like this:
> >
> >  SELECT 'i'::citext = 'İ'::citext AS t;
> >   t
> >  ---
> > - t
> > + f
> >  (1 row)
> >
> > I tried to replicate the test's results by hand and with any collation
> > that I tried (including --locale="Turkish") this test failed
> >
> > Also an interesing result of my tesing. If you initialize you DB
> > with -E utf-8 --locale="Turkish" and then run select LOWER('İ');
> > the output will be this:
> >  lower
> > -------
> >  İ
> > (1 row)
> >
> > Which I find strange since lower() uses collation that was passed
> > (default in this case but still)
>
> Wouldn't we be better off finding a Windows fix for this, instead of
> sweeping it under the rug?

Given the sorry state of our Windows locale support, I've started
wondering about deleting it and telling users to adopt our nascent
built-in support or ICU[1].

This other thread [2] says the sorting is intransitive so I don't
think it really meets our needs anyway.

[1]
https://www.postgresql.org/message-id/flat/CA%2BhUKGJhV__g_TJ0jVqPbnTuqT%2B%2BM6KFv2wj%2B9AV-cABNCXN6Q%40mail.gmail.com#bc35c0b88962ff8c24c27aecc1bca72e
[2] https://www.postgresql.org/message-id/flat/1407a2c0-062b-4e4c-b728-438fdff5cb07%40manitou-mail.org



pgsql-hackers by date:

Previous
From: jian he
Date:
Subject: Re: SQL:2011 application time
Next
From: "Jingxian Li"
Date:
Subject: Re: [PATCH] LockAcquireExtended improvement