From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Jeff Davis <pgsql(at)j-davis(dot)com> |
Cc: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Daniel Verite <daniel(at)manitou-mail(dot)org>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: pg_collation.collversion for C.UTF-8 |
Date: | 2023-05-25 18:48:56 |
Message-ID: | 1559006.1685040536@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Jeff Davis <pgsql(at)j-davis(dot)com> writes:
> What should we do with locales like C.UTF-8 in both libc and ICU?
I vote for passing those to the existing C-specific code paths,
whereever we have any (not sure that we do for <ctype.h> functionality).
The semantics are quite well-defined and I can see no good coming of
allowing either provider to mess with them.
> If we capture it like the C locale, then where do we draw the line? Any
> locale that begins with "C."? What if the language part is C but there
> is some other part to the locale? What about lower case? Should all of
> these apply the same way except with POSIX? What about backwards
> compatibility?
Probably "C", or "C.anything", or "POSIX", or "POSIX.anything".
Case-independent might be good, but we haven't accepted such in
the past, so I don't feel strongly about it. (Arguably, passing
lower case "c" to the provider would provide an "out" to anybody
who dislikes our choices here.)
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Jacob Champion | 2023-05-25 19:27:06 | Re: Docs: Encourage strong server verification with SCRAM |
Previous Message | Jeff Davis | 2023-05-25 18:30:11 | Re: pg_collation.collversion for C.UTF-8 |