Re: Wrong sorting on docker image

Поиск
Список
Период
Сортировка
От Thomas Munro
Тема Re: Wrong sorting on docker image
Дата
Msg-id CA+hUKGL10TtareqaGwrt5NcSMgmJqKuRiFbNV3S4hG=9K_prDQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Wrong sorting on docker image  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-general
On Sun, Oct 17, 2021 at 4:42 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Speaking of ICU, if you are using an ICU-enabled Postgres build,
> maybe you could find an ICU collation that acts the way you want.
> This wouldn't be a perfect solution, because we don't yet have
> the ability to set an ICU collation as a database's default.
> But you can attach ICU collations to individual text columns,
> and maybe that would be a good enough workaround.

For what it's worth, ICU's "ru-RU-x-icu" and FreeBSD's libc agree with
glibc on these sort orders, so I suspect this might be coming from
CLDR/UCA/DUCET/ISO 14651 common/synchronised data.  It does look quite
suspicious to me, but I don't know Russian and I'm only speculating
wildly here: it does look as if ё is perhaps getting a lower weight
than it should.  That said, it seems strange that something so basic
should be wrong.  Nosing around in the unicode.org issue tracker, it
seems as though some people might think there is something funny about
Ё (and I wonder if there are/were similar issues with й/Й):

https://unicode-org.atlassian.net/browse/CLDR-2745?jql=text%20~%20%22%D0%81%22
https://unicode-org.atlassian.net/browse/CLDR-1974?jql=text%20~%20%22%D0%81%22
(and more)

It's probably not a great idea, but for the record, you can build your
own collation for glibc and other POSIX-oid systems.  For example, see
glibc commit 159738548130d5ac4fe6178977e940ed5f8cfdc4, where they
previously had customisations on top of the iso14651_t1 file to
reorder a special Ukrainian character in ru_RU, so in theory you could
reorder ё/Ё with a similar local hack and call it ru_RU_X...  I also
wonder if there is some magic switch you can put after an @ symbol on
ICU collations that would change this, perhaps some way to disable the
"contractions" that are potentially implicated here.  Not sure.



В списке pgsql-general по дате отправления:

Предыдущее
От: Adrian Klaver
Дата:
Сообщение: Re: "two time periods with only an endpoint in common do not overlap" ???
Следующее
От: Francisco Olarte
Дата:
Сообщение: Re: "two time periods with only an endpoint in common do not overlap" ???