From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
Cc: | Daniel Verite <daniel(at)manitou-mail(dot)org>, Peter Geoghegan <pg(at)bowt(dot)ie>, 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-07 22:27:21 |
Message-ID: | 5667.1502144841@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> writes:
> It has never been the case that there is a guarantee that a new
> operating system environment will have the same or more collations
> available as an earlier version. Even glibc removes or renames locales.
Indeed, and one of the alleged selling points of ICU was greater stability
of collation behaviors (including naming). I'd like to try to actually
achieve that.
> In this particular case, you can create user-defined collations to fill
> in the missing names if you want.
NO. YOU. CAN'T. At least not with convenient upgrade methods like
pg_upgrade. If the collation name isn't produced by the newer version's
initdb, pg_upgrade will fail.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2017-08-07 22:54:43 | Re: Crash report for some ICU-52 (debian8) COLLATE and work_mem values |
Previous Message | Peter Eisentraut | 2017-08-07 22:07:18 | Re: Crash report for some ICU-52 (debian8) COLLATE and work_mem values |
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2017-08-07 22:54:43 | Re: Crash report for some ICU-52 (debian8) COLLATE and work_mem values |
Previous Message | Tom Lane | 2017-08-07 22:23:56 | Re: ICU collation variant keywords and pg_collation entries (Was: [BUGS] Crash report for some ICU-52 (debian8) COLLATE and work_mem values) |