Re: ICU for global collation - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: ICU for global collation
Date
Msg-id bba413de-5548-3480-e8f8-1ced562a866b@enterprisedb.com
Whole thread Raw
In response to Re: ICU for global collation  (Julien Rouhaud <rjuju123@gmail.com>)
Responses Re: ICU for global collation
Re: ICU for global collation
List 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.



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Proposal: remove obsolete hot-standby testing infrastructure
Next
From: Alvaro Herrera
Date:
Subject: Re: SKIP LOCKED assert triggered