On Thu, Dec 12, 2019 at 05:03:59AM +0000, Andrew Gierth wrote:
> Rich> I doubt that my use will notice meaningful differences. Since
> Rich> there are only two or three databases in UTF8 and its collation
> Rich> perhaps I'll convert those to LATIN1 and C.
>
> Note that it's perfectly fine to use UTF8 encoding and C collation (this
> has the effect of sorting strings in Unicode codepoint order); this is
> as fast for comparisons as LATIN1/C is.
>
> For those cases where you need data to be sorted in a
> culturally-meaningful order rather than in codepoint order, you can set
> collations on specific columns or in individual queries.
Nice, thanks for pointing that out. One addition: while this
may seem like "the" magic bullet it should be noted that one
will need additional indexes for culturally-meaningful ORDER
BY sorts to be fast (while having a default non-C collation
one will get a by-default culturally-meaningful index for
that one non-C locale).
Question: is C collation expected to be future-proof /
rock-solid /stable -- like UTF8 for encoding choice -- or
could it end up like the SQL-ASCII encoding did: Yeah, we
support it, it's been in use a long time, it should work,
but, nah, one doesn't really want to choose it over UTF8 if
at all possible, or at least know *exactly* what one is doing
and BTW YMMV ?
Karsten
--
GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B