Re: pgsql: Allow tailoring of ICU locales with custom rules

Поиск
Список
Период
Сортировка
От Jeff Davis
Тема Re: pgsql: Allow tailoring of ICU locales with custom rules
Дата
Msg-id 0aa4f0301450f75b4a57a17bb4d652aee99eeb41.camel@j-davis.com
обсуждение исходный текст
Ответ на Re: pgsql: Allow tailoring of ICU locales with custom rules  (Peter Eisentraut <peter@eisentraut.org>)
Ответы Re: pgsql: Allow tailoring of ICU locales with custom rules
Список pgsql-hackers
On Mon, 2023-08-14 at 10:34 +0200, Peter Eisentraut wrote:
> I have investigated this.  My assessment is that how PostgreSQL
> interfaces with ICU is correct.  Whether what ICU does is correct
> might
> be debatable.  I have filed a bug with ICU about this:
> https://unicode-org.atlassian.net/browse/ICU-22456 , but there is no
> response yet.

Is everything other than the language and region simply discarded when
a rules string is present, or are some attributes preserved, or is
there some other nuance?

> You can work around this by including the desired attributes in the
> rules string, for example
>
>      create collation c3 (provider=icu,
>        locale='und-u-ka-shifted-ks-level1',
>        rules='[alternate shifted][strength 1]',
>        deterministic=false);
>
> So I don't think there is anything we need to do here for PostgreSQL
> 16.

Is there some way we can warn a user that some attributes will be
discarded, or improve the documentation? Letting the user figure this
out for themselves doesn't seem right.

Are you sure we want to allow rules for the database default collation
in 16, or should we start with just allowing them in CREATE COLLATION
and then expand to the database default collation later? I'm still a
bit concerned about users getting too fancy with daticurules, and
ending up not being able to connect to their database anymore.

Regards,
    Jeff Davis




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

Предыдущее
От: Nathan Bossart
Дата:
Сообщение: Re: should frontend tools use syncfs() ?
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: Make all Perl warnings fatal