Re: pg_collation.collversion for C.UTF-8 - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pg_collation.collversion for C.UTF-8
Date
Msg-id 1559006.1685040536@sss.pgh.pa.us
Whole thread Raw
In response to Re: pg_collation.collversion for C.UTF-8  (Jeff Davis <pgsql@j-davis.com>)
Responses Re: pg_collation.collversion for C.UTF-8
List 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 by date:

Previous
From: Jeff Davis
Date:
Subject: Re: pg_collation.collversion for C.UTF-8
Next
From: Jacob Champion
Date:
Subject: Re: Docs: Encourage strong server verification with SCRAM