| From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
|---|---|
| To: | Peter Geoghegan <pg(at)bowt(dot)ie>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Daniel Verite <daniel(at)manitou-mail(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: ICU collation variant keywords and pg_collation entries (Was: [BUGS] Crash report for some ICU-52 (debian8) COLLATE and work_mem values) |
| Date: | 2017-08-14 15:40:12 |
| Message-ID: | f80e8121-79de-f508-2433-161e544b6672@2ndquadrant.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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
> pg_import_system_collations()).
>
> If I add such a test to CollationCreate(), it does a reasonable job of
> sanitizing, while preserving the spirit of the BCP 47 language tag
> format by not assuming that the user didn't specify a brand new locale
> that it hasn't heard of.
I'm not sure what you are proposing here. Convert the input to CREATE
COLLATION to a BCP 47 language tag?
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2017-08-14 15:46:10 | Re: shared memory based stat collector (was: Sharing record typmods between backends) |
| Previous Message | Stephen Frost | 2017-08-14 15:28:16 | Re: pg_stop_backup(wait_for_archive := true) on standby server |