Re: ICU for global collation

From: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
To: Julien Rouhaud <rjuju123(at)gmail(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Daniel Verite <daniel(at)manitou-mail(dot)org>
Subject: Re: ICU for global collation
Date: 2022-01-04 16:03:10
Message-ID: bba413de-5548-3480-e8f8-1ced562a866b@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 04.01.22 03:21, Julien Rouhaud wrote:
>> @@ -2774,6 +2776,7 @@ dumpDatabase(Archive *fout)
>> appendPQExpBuffer(dbQry, "SELECT tableoid, oid, datname, "
>> "(%s datdba) AS dba, "
>> "pg_encoding_to_char(encoding) AS encoding, "
>> + "datcollprovider, "
>
> This needs to be in a new pg 15+ branch, not in the pg 9.3+.

ok

>> - if (!lc_collate_is_c(collid) && collid != DEFAULT_COLLATION_OID)
>> - mylocale = pg_newlocale_from_collation(collid);
>> + if (!lc_collate_is_c(collid))
>> + {
>> + if (collid != DEFAULT_COLLATION_OID)
>> + mylocale = pg_newlocale_from_collation(collid);
>> + else if (default_locale.provider == COLLPROVIDER_ICU)
>> + mylocale = &default_locale;
>> + }
>
> There are really a lot of places with this new code. Maybe it could be some
> new function/macro to wrap that for the normal case (e.g. not formatting.c)?

Right, we could just put this into pg_newlocale_from_collation(), but
the comment there says

* In fact, they shouldn't call this function at all when they are dealing
* with the default locale. That can save quite a bit in hotspots.

I don't know how to assess that.

We could pack this into a macro or inline function if we are concerned
about this.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2022-01-04 16:03:38 Re: SKIP LOCKED assert triggered
Previous Message Tom Lane 2022-01-04 15:33:00 Re: Proposal: remove obsolete hot-standby testing infrastructure