Re: [BUGS] Turkish locale bug

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [BUGS] Turkish locale bug
Дата
Msg-id 10734.982636214@sss.pgh.pa.us
обсуждение исходный текст
Ответы Re: Re: [BUGS] Turkish locale bug  (Larry Rosenman <ler@lerctr.org>)
Список pgsql-hackers
Sezai YILMAZ <sezaiy@ata.cs.hun.edu.tr> writes:
> With Turkish locale it is not possible to write SQL queries in 
> CAPITAL letters. SQL identifiers like "INSERT" and "UNION" first 
> are downgraded to "�nsert" and "un�on". Then "�nsert" and "un�on"
> does not match as SQL identifier.

Ugh.

>                     for(i = 0; yytext[i]; i++)
>                           if (isascii((unsigned char)yytext[i]) &&
>                                 isupper(yytext[i]))
>                                 yytext[i] = tolower(yytext[i]);

> I think it should be better to use another thing which does what 
> function tolower() does but only in English language. This should
> stay in English locale. I think this will solve the problem.

> yytext[i] += 32;

Hm.  Several problems here:

(1) This solution would break in other locales where isupper() may
return TRUE for characters other than 'A'..'Z'.

(2) We could fix that by gutting the isascii/isupper test as well,
reducing it to "yytext[i] >= 'A' && yytext[i] <= 'Z'", but I'd prefer to
still be able to say that "identifiers fold to lower case" works for
whatever the local locale thinks is upper and lower case.  It would be
strange if identifier folding did not agree with the SQL lower()
function.

(3) I do not like the idea of hard-wiring knowledge of ASCII encoding
here, even if it's unlikely that anyone would ever try to run Postgres
on a non-ASCII-based system.

I see your problem, but I'm not sure of a solution that doesn't have bad
side-effects elsewhere.  Ideas anyone?
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: floating point representationu
Следующее
От: Hiroshi Inoue
Дата:
Сообщение: Re: floating point representationu