From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Daniel Verite <daniel(at)manitou-mail(dot)org>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Create collation reporting the ICU locale display name |
Date: | 2019-09-13 04:31:17 |
Message-ID: | 23501.1568349077@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Michael Paquier <michael(at)paquier(dot)xyz> writes:
> On Thu, Sep 12, 2019 at 03:03:43PM -0400, Tom Lane wrote:
>> The idea of having CREATE COLLATION automatically create a comment
>> is sort of interesting, although it seems pretty orthogonal to
>> normal command behavior. I wonder whether the seeming need for
>> this indicates that we should add a descriptive field to pg_collation
>> proper, and not usurp the user-oriented comment feature for that.
>>
>> The difficulty with localization is that whatever we put into
>> template1 has got to be ASCII-only, so that the template DB
>> can be copied to other encodings. I suppose we could consider
>> having CREATE COLLATION act differently during initdb than
>> later, but that seems ugly too.
> Or could it make sense to provide a system function which returns a
> collation description for at least an ICU-provided one? We could make
> use of that in psql for example.
Oh, that seems like a good way to tackle it.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2019-09-13 05:12:22 | Re: [HACKERS] [PATCH] pageinspect function to decode infomasks |
Previous Message | Michael Paquier | 2019-09-13 04:30:07 | Re: refactoring - share str2*int64 functions |