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

From Peter Eisentraut
Subject Re: ICU for global collation
Date
Msg-id 704405ed-f1fa-d2a7-b9f9-48a07fb45648@enterprisedb.com
Whole thread Raw
In response to Re: ICU for global collation  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
Responses Re: ICU for global collation  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
Re: ICU for global collation  (Justin Pryzby <pryzby@telsasoft.com>)
List pgsql-hackers
On 27.01.22 09:10, Peter Eisentraut wrote:
> On 21.01.22 17:13, Julien Rouhaud wrote:
>> On Fri, Jan 21, 2022 at 03:24:02PM +0100, Peter Eisentraut wrote:
>>> On 21.01.22 14:51, Julien Rouhaud wrote:
>>>> Is that change intended?  There isn't any usage of the 
>>>> collversionstr before
>>>> the possible error when actual_versionstr is missing.
>>>
>>> I wanted to move it closer to the SysCacheGetAttr() where the "datum" 
>>> value
>>> is obtained.  It seemed weird to get the datum, then do other things, 
>>> then
>>> decode the datum.
>>
>> Oh ok.  It won't make much difference performance-wise, so no objection.
> 
> I have committed this and will provide follow-up patches in the next few 
> days.

Here is the main patch rebased on the various changes that have been 
committed in the meantime.  There is still some work to be done on the 
user interfaces of initdb, createdb, etc.

I have split out the database-level collation version tracking into a 
separate patch [0].  I think we should get that one in first and then 
refresh this one.

[0]: 
https://www.postgresql.org/message-id/flat/f0ff3190-29a3-5b39-a179-fa32eee57db6%40enterprisedb.com
Attachment

pgsql-hackers by date:

Previous
From: torikoshia
Date:
Subject: Re: RFC: Logging plan of the running query
Next
From: Robert Haas
Date:
Subject: Re: make MaxBackends available in _PG_init