Re: multibyte-character aware support for function "downcase_truncate_identifier()"

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, Rajanikant Chirmade <rajanikant(dot)chirmade(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: multibyte-character aware support for function "downcase_truncate_identifier()"
Date: 2010-11-23 19:27:42
Message-ID: 1290540462.24521.6.camel@vanquo.pezone.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2010-11-23 19:29:03 Re: patch: fix performance problems with repated decomprimation of varlena values in plpgsql
Previous Message David E. Wheeler 2010-11-23 19:01:33 Re: s/LABEL/VALUE/ for ENUMs