Re: 7.4.1 release status - Turkish Locale - Mailing list pgsql-hackers

From Tom Lane
Subject Re: 7.4.1 release status - Turkish Locale
Date
Msg-id 15123.1075623446@sss.pgh.pa.us
Whole thread Raw
In response to Re: 7.4.1 release status - Turkish Locale  ("Nicolai Tufar" <ntufar@pisem.net>)
Responses Re: 7.4.1 release status - Turkish Locale  ("Nicolai Tufar" <ntufar@pisem.net>)
Turkish Locale in Identifiers (contd.)  ("Nicolai Tufar" <ntufar@pisem.net>)
Re: 7.4.1 release status - Turkish Locale  (Greg Stark <gsstark@mit.edu>)
List pgsql-hackers
"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'?

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


pgsql-hackers by date:

Previous
From: "Nicolai Tufar"
Date:
Subject: Re: 7.4.1 release status - Turkish Locale
Next
From: "Nicolai Tufar"
Date:
Subject: Re: 7.4.1 release status - Turkish Locale