Re: [HACKERS] Can ICU be used for a database's default sort order?

Поиск
Список
Период
Сортировка
От Michail Nikolaev
Тема Re: [HACKERS] Can ICU be used for a database's default sort order?
Дата
Msg-id CANtu0oicb3m3_K6EunaBxm3b=M5+WR9=bOcR9KkdN5xPmu-i7w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Can ICU be used for a database's default sort order?  (Andrey Borodin <x4mmm@yandex-team.ru>)
Список pgsql-hackers
Hello.

Just want to inform:
I have run check,installcheck,plcheck,contribcheck,modulescheck,ecpgcheck,isolationcheck,upgradecheck tests on Windows 10, VC2017 with patch applied on top of 2a41507dab0f293ff241fe8ae326065998668af8 as Andrey asked me.

Everything is passing with and without $config->{icu} = 'D:\Dev\postgres\icu\';

Best regards, 
Michail.


пт, 16 февр. 2018 г. в 11:13, Andrey Borodin <x4mmm@yandex-team.ru>:
Hi everyone!

> 10 февр. 2018 г., в 20:45, Andrey Borodin <x4mmm@yandex-team.ru> написал(а):
>
> I'm planning to provide review
>

So, I was looking into the patch.
The patch adds:
1. Ability to specify collation provider (with version) in --locale for initdb and createdb.
2. Changes to locale checks
3. Sets ICU as default collation provider. For example "ru_RU@icu.153.80.32.1" is default on my machine with patch
4. Tests and necessary changes to documentation

With patch I get correct ICU ordering by default
postgres=# select unnest(array['е','ё','ж']) order by 1;
 unnest
--------
 е
 ё
 ж
(3 rows)

While libc locale provides incorrect order (I also get same ordering by default without patch)

postgres=# select c from unnest(array['е','ё','ж']) c order by c collate "ru_RU";
 c
---
 е
 ж
 ё
(3 rows)


Unfortunately, neither "ru_RU@icu.153.80.32.1" (exposed by LC_COLLATE and other places) nor "ru_RU@icu" cannot be used by collate SQL clause.
Also, patch removes compatibility with MSVC 1800 (Visual Studio 2013) on Windows XP and Windows Server 2003. This is done to use newer locale-related functions in VS2013 build.

If the database was initialized with default locale without this patch, one cannot connect to it anymore
psql: FATAL:  could not find out the collation provider for datcollate "ru_RU.UTF-8" of database "postgres"
This problem is mentioned in commit message of the patch. I think that this problem should be addressed somehow.
What do you think?

Overall patch looks solid and thoughtful work and adds important functionality.

Best regards, Andrey Borodin.

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

Предыдущее
От: Andreas Seltenreich
Дата:
Сообщение: Re: [HACKERS] MERGE SQL Statement for PG11
Следующее
От: Joe Conway
Дата:
Сообщение: Re: missing toast table for pg_policy