Tom Lane <tgl@sss.pgh.pa.us> writes:
> It seems to me that that's too narrow a definition of the problem.
> I think we should state our goal as "we don't want bizarre locale
> definitions to interfere with downcasing of the basic ASCII letters".
> If we put in a special case for 'I' we will fix the known problem
> with Turkish, but what other strange locales might be out there?
> And if we don't trust tolower() for 'I', why should we trust it
> for 'A'-'Z'?
But then wouldn't it be a little weird for Turkish table and column names to
treat "I and "Ý" (I think that's a dotted capital I) as equivalent to "i"
instead of "ý" "i" respectively. (I think that first one was a dotless i).
Perhaps what really ought to be happening is that the downcasing should be
done separately for keywords, or postponed until the point where it's checked
to see if it's a keyword. Then it could be done using an entirely
ascii-centric bit-twiddling implementation.
If it matches an SQL keyword after being downcased the old fashioned way, then
it's an SQL keyword. If not then the locale-aware tolower() would be
appropriate for tables, columns, etc.
But then perhaps that's unnecessarily complex.
--
greg
