On 8/7/17 21:00, Peter Geoghegan wrote:
> Actually, it's *impossible* for ICU to fail to accept any string as a
> valid locale within CREATE COLLATION, because CollationCreate() simply
> doesn't sanitize ICU names. It doesn't do something like call
> get_icu_language_tag(), unlike initdb (within
>
On Mon, Aug 7, 2017 at 3:23 PM, Tom Lane wrote:
> The thing that I'm particularly thinking about is that if someone wants
> an ICU variant collation that we didn't make initdb provide, they'll do
> a CREATE COLLATION and go use it. At update time, pg_dump or pg_upgrade
> will
Peter Eisentraut writes:
> On 8/6/17 20:07, Peter Geoghegan wrote:
>> I've looked into this. I'll give an example of what keyword variants
>> there are for Greek, and then discuss what I think each is.
> I'm not sure why we want to get into editorializing this.
On Mon, Aug 7, 2017 at 2:50 PM, Peter Eisentraut
wrote:
> On 8/6/17 20:07, Peter Geoghegan wrote:
>> I've looked into this. I'll give an example of what keyword variants
>> there are for Greek, and then discuss what I think each is.
>
> I'm not sure why we want
On 8/6/17 20:07, Peter Geoghegan wrote:
> I've looked into this. I'll give an example of what keyword variants
> there are for Greek, and then discuss what I think each is.
I'm not sure why we want to get into editorializing this. We query ICU
for the names of distinct collations and use that.
On Sun, Aug 6, 2017 at 1:06 PM, Peter Geoghegan wrote:
> On Sat, Aug 5, 2017 at 8:26 PM, Tom Lane wrote:
>> I'm quite disturbed though that the set of installed collations on these
>> two test cases seem to be entirely different both from each other and from
>>