"Tom Lane" tgl@sss.pgh.pa.us wrote:
>
>"Nicolai Tufar" <ntufar@pisem.net> writes:
>>> A possible compromise is to apply ASCII downcasing (same as in
>>> keywords.c) for 7-bit-ASCII characters, and apply tolower() only
>>> for character codes above 127. In other words
>
>> If we go this way why not make a special case only and only for 'I'
>> Character and not all 7-bit ASCII:
>
> 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'?
To my knowledge no other locale have similar problems. At least nobody
complained so far while Turk users are rising their voices for many
years
now. Let try and put this very special case, together with an extensive
explanation in comment and see if someone complains. And by the way,
national characters in table, column, index or function names is
something
that never happens in production databases.
As for 'A'-'Z'^, it was pointed to me that SQL99 standard states that
identifier names need to be downcasted in locale-dependent manner.
Would you like me to create a patch that would touch only
src/backend/parser/scan.l, introduce a special case for 'I'
and include an explanation in comment?
> What it comes down to is that by training and experience, I always
> expect that any bug might be just one example of a whole class of
bugs.
> You have to look for the related cases that might happen in future,
> not only fix the case that's under your nose.
>
> regards, tom lane
Regards,
Nicolai Tufar