From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com>, Jeremy Schneider <schneider(at)ardentperf(dot)com> |
Cc: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, Daniel Verite <daniel(at)manitou-mail(dot)org>, Noah Misch <noah(at)leadboat(dot)com>, Peter Eisentraut <peter(at)eisentraut(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [18] Policy on IMMUTABLE functions and Unicode updates |
Date: | 2024-07-23 17:03:29 |
Message-ID: | 3faa3e88f6336c8a61aab732f6d2f3f1f26eee7a.camel@j-davis.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, 2024-07-23 at 08:49 -0400, Robert Haas wrote:
> Hmm. I think we might have some unique problems due to the fact that
> we rely partly on the operating system behavior, partly on libicu,
> and
> partly on our own internal tables.
The reliance on the OS is especially problematic for reasons that have
already been discussed extensively.
One of my strongest motivations for PG_C_UTF8 was that there was still
a use case for libc in PG16: the "C.utf-8" locale, which is not
supported at all in ICU. Daniel Vérité made me aware of the importance
of this locale, which offers code point order collation combined with
Unicode ctype semantics.
With PG17, between ICU and the builtin provider, there's little
remaining reason to use libc (aside from legacy).
Regards,
Jeff Davis
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2024-07-23 17:32:29 | Re: Direct SSL connection and ALPN loose ends |
Previous Message | Paul Jungwirth | 2024-07-23 17:02:36 | Re: [PATCH] GROUP BY ALL |