Re: Crash report for some ICU-52 (debian8) COLLATE and work_mem values

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Daniel Verite <daniel(at)manitou-mail(dot)org>, PostgreSQL mailing lists <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: Crash report for some ICU-52 (debian8) COLLATE and work_mem values
Date: 2017-08-14 19:54:20
Message-ID: CAH2-Wzno4cHke3+3dJPtOT7fKnva9Asr=JM-CG2yE33JPfrGSw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

On Mon, Aug 14, 2017 at 12:17 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Maybe I'm missing something, but I didn't think there would be anything
> terribly disastrous about having pg_import_system_collations() install
> these descriptions as comments in v10 and then changing it to put them
> directly into pg_collation in later versions. We'd have to adapt the
> behavior of psql's \dO, but that's true no matter when we change that.

Well, I don't think you're going to get on board with the idea of
having CREATE COLLATION add a comment (and I agree that that's a bad
idea), so CREATE COLLATION is in a very bad spot if we put this off
for a release.

Unless we add an ICU-owned pg_collation column for the human-readable
ICU string, CREATE COLLATION will not let the user determine what ICU
thinks the collation/language is from within Postgres. This seems
arbitrarily different from the situation with initdb ICU collations,
where currently the ICU string comment is added. Importantly, not
having the ICU string deprives the user of a way of determining
whether or not ICU has even heard of the language/region they
specified. The language tags are supposed to be forgiving, but that
does mean that ICU won't actually complain when the user fat-fingers
their CREATE COLLATION language tag.

(Note that this doesn't mean that we couldn't provide *minimal*
sanitization of language tags by CREATE COLLATION; we can and should
reject multiple "co" subtags, and similar unambiguously bogus
subtags.)

>> I don't think we have pg_import_system_collations's behavior all
>> worked out just yet.
>
> Agreed, but we can probably tweak that without forcing a catversion
> bump.

True.

I might have used the wrong terminology on this "locales vs.
collations" thing. Perhaps what we actually need is pg_collation
entries at initdb time that are an enumeration of all locales *and
their regions*, as opposed to all locales. I'm researching this now.

--
Peter Geoghegan

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2017-08-14 20:13:33 Re: Crash report for some ICU-52 (debian8) COLLATE and work_mem values
Previous Message Tom Lane 2017-08-14 19:17:17 Re: Crash report for some ICU-52 (debian8) COLLATE and work_mem values

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2017-08-14 20:00:44 Re: Foreign tables privileges not shown in information_schema.table_privileges
Previous Message Peter Eisentraut 2017-08-14 19:48:51 Re: Add Roman numeral conversion to to_number