Re: Re: [BUGS] Turkish locale bug
От | Larry Rosenman |
---|---|
Тема | Re: Re: [BUGS] Turkish locale bug |
Дата | |
Msg-id | 20010219203915.B1309@lerami.lerctr.org обсуждение исходный текст |
Ответ на | Re: [BUGS] Turkish locale bug (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Re: [BUGS] Turkish locale bug
|
Список | pgsql-hackers |
* Tom Lane <tgl@sss.pgh.pa.us> [010219 20:31]: > > 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. What about EBCDIC (IBM MainFrame, I.E. Linux on S/390, Z/390). EBCDIC has 3 different ranges that contain letters. X'C1'-X'C9' (A-I) X'D1'-X'D9' (J-R) X'E2'-X'E9' (S-Z) and the *LOWER* case ones subtract X'40' (SPACE) to get there. Plus Numbers are X'F0'- X'F9'. This is from 5 year ago mainframe assembler memory.... > > (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. Not unlikely now. See APACHE and other ports to now handle EBCDIC. > > I see your problem, but I'm not sure of a solution that doesn't have bad > side-effects elsewhere. Ideas anyone? > -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: ler@lerctr.org US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
В списке pgsql-hackers по дате отправления: