Re: Re: [BUGS] Turkish locale bug - Mailing list pgsql-hackers

From Larry Rosenman
Subject Re: Re: [BUGS] Turkish locale bug
Date
Msg-id 20010219203915.B1309@lerami.lerctr.org
Whole thread Raw
In response to Re: [BUGS] Turkish locale bug  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Re: [BUGS] Turkish locale bug
List 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 by date:

Previous
From: Hiroshi Inoue
Date:
Subject: Re: floating point representationu
Next
From: Tom Lane
Date:
Subject: Re: Re: [BUGS] Turkish locale bug