On sön, 2010-11-21 at 18:48 -0500, Tom Lane wrote:
> Yeah. I'm actually not sure that the SQL committee has thought very
> hard about this, because the spec is worded as though they think that
> "Unicode case normalization" is all they have to say to uniquely
> define what to do. The Unicode guys recognize that case mapping is
> locale-specific, which puts us right back at square one. But leaving
> spec compliance aside, we know from bitter experience that we cannot
> use a definition that lets the Turkish locale fool with the mapping of
> i/I. I suspect that locale-dependent mappings of any other characters
> are just as bad, we simply haven't had enough users burnt by such
> cases to have an institutional memory of it.
The number of locale-dependent case mappings in the entire universe of
Unicode is actually limited to 7 cases for Lithuanian and 8 cases for
Turkish. (ftp://ftp.unicode.org/Public/UNIDATA/SpecialCasing.txt) So it
would be fair to say that there is a "default" case mapping, and that is
what the SQL standard presumably refers to.
One thing that we could do is let the user declare that he thinks his
current locale is consistent with the Unicode case normalization, and
apply the full Unicode conversion if so.