Re: [HACKERS] Re: Turkish locale bug

* Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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(at)lerctr(dot)org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749