| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Greg Stark <stark(at)mit(dot)edu> |
| Cc: | Jakob Egger <jakob(at)eggerapps(dot)at>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Bussmann Tobias <tobias(dot)bussmann(at)scnat(dot)ch>, Palle Girgensohn <girgen(at)pingpong(dot)net>, Magnus Hagander <magnus(at)hagander(dot)net>, Geoff Montee <geoff(dot)montee(at)gmail(dot)com>, Dave Page <dpage(at)postgresql(dot)org> |
| Subject: | Re: [pgsql-packagers] Palle Girgensohn's ICU patch |
| Date: | 2014-11-27 15:03:29 |
| Message-ID: | 3921.1417100609@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Greg Stark <stark(at)mit(dot)edu> writes:
> Hm. Actually the pg_collation catalog might give a handy way out for the
> issue of being inconsistent with the system collation. We could support
> both sets of collations and let the user select an ICU collation or system
> collation at runtime.
+1 ... this seems like a nice end-run around the backwards compatibility
problem.
Another issue is that (AFAIK) ICU doesn't support any non-Unicode
encodings, which means that a build supporting *only* ICU collations is a
nonstarter IMO. So we really need a way to deal with both system and ICU
collations, and treating the latter as a separate subset of pg_collation
seems like a decent way to do that. (ISTR some discussion about forcibly
converting strings in other encodings to Unicode to compare them, but
I sure don't want to do that. I think it'd be saner just to mark the
ICU collations as only compatible with UTF8 database encoding.)
regards, tom lane
PS: I've removed pgsql-packagers from the cc, this thread is no
longer relevant to them.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2014-11-27 16:24:11 | Re: pg_dump/pg_restore seem broken on hamerkop |
| Previous Message | Andrew Dunstan | 2014-11-27 15:02:40 | Re: pg_regress and --dbname option / multiple databases |