Tom Lane wrote:
>
> Sezai YILMAZ <[EMAIL PROTECTED]> 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 id
Thomas Lockhart <[EMAIL PROTECTED]> writes:
> (Just a follow up...)
> I haven't had time to review the spec on this, but my recollection is
> that the entire SQL language can be described using the SQL_ASCII
> character set. I would assume that this might include unquoted
> identifiers.
The keyw
> > Anyway, your proposal is just fine since we haven't decoupled these
> > things farther back in the server. But eventually we should hope to have
> > SQL_ASCII and other character sets enforced in context.
> Now I'm confused. Are you saying that we *should* treat identifier case
> under ASCII
> > Anyway, your proposal is just fine since we haven't decoupled these
> > things farther back in the server. But eventually we should hope to have
> > SQL_ASCII and other character sets enforced in context.
>
> Now I'm confused. Are you saying that we *should* treat identifier case
> under AS
Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
>> Now I'm confused. Are you saying that we *should* treat identifier case
>> under ASCII rules only? That seems like a step backwards to me, but
>> then I don't use any non-US locale myself...
> I think we need to treat anything that is not q
Thomas Lockhart <[EMAIL PROTECTED]> writes:
> Anyway, your proposal is just fine since we haven't decoupled these
> things farther back in the server. But eventually we should hope to have
> SQL_ASCII and other character sets enforced in context.
Now I'm confused. Are you saying that we *should*
Merhaba Sezai!
> I am starting to think that the only real solution is a special case
> for Turkish users. Perhaps use tolower() normally but have a compile-
> time option to use a non-locale-aware method:
istm that this illustrates the tip of the locale iceberg as we think
about moving to a mo
Sezai YILMAZ <[EMAIL PROTECTED]> writes:
> You are right. What about this one?
> setlocale(LC_ALL, "C");
> for(i = 0; yytext[i]; i++)
> if (isascii((unsigned char)yytext[i]) &&
> isupper(yytext[i]))
Larry Rosenman <[EMAIL PROTECTED]> writes:
> What about EBCDIC (IBM MainFrame, I.E. Linux on S/390, Z/390).
Right, that was what I meant about not wanting to hardwire assumptions
about ASCII.
We could instead code it as
if (isupper(ch))
ch = ch + ('a' - 'A');
which I believe
* Tom Lane <[EMAIL PROTECTED]> [010219 21:02]:
> Larry Rosenman <[EMAIL PROTECTED]> writes:
> > What about EBCDIC (IBM MainFrame, I.E. Linux on S/390, Z/390).
>
> Right, that was what I meant about not wanting to hardwire assumptions
> about ASCII.
>
> We could instead code it as
>
> if
* Tom Lane <[EMAIL PROTECTED]> [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
Sezai YILMAZ <[EMAIL PROTECTED]> 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.
>
12 matches
Mail list logo
