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

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Peter Eisentraut <peter(at)eisentraut(dot)org>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Cc: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Subject: Re: pgsql: Allow tailoring of ICU locales with custom rules
Date: 2023-08-22 17:25:29
Message-ID: 0aa4f0301450f75b4a57a17bb4d652aee99eeb41.camel@j-davis.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers 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

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Alvaro Herrera 2023-08-22 18:45:27 pgsql: Add comment missing in a4a232b1e702
Previous Message Peter Eisentraut 2023-08-22 09:21:21 pgsql: Add list of acknowledgments to release notes

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2023-08-22 18:46:46 Re: Make all Perl warnings fatal
Previous Message Nathan Bossart 2023-08-22 17:11:10 Re: should frontend tools use syncfs() ?