Re: pg_collation.collversion for C.UTF-8
| От | Tom Lane |
|---|---|
| Тема | Re: pg_collation.collversion for C.UTF-8 |
| Дата | |
| Msg-id | 1559006.1685040536@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Re: pg_collation.collversion for C.UTF-8 (Jeff Davis <pgsql@j-davis.com>) |
| Ответы |
Re: pg_collation.collversion for C.UTF-8
|
| Список | pgsql-hackers |
Jeff Davis <pgsql@j-davis.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
В списке pgsql-hackers по дате отправления: