| 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: | Whole Thread | Raw Message | 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 |