Turkish Locale in Identifiers (contd.)

> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> "Nicolai Tufar" <ntufar(at)pisem(dot)net> writes:
> >> A possible compromise is to apply ASCII downcasing (same as in
> >> keywords.c) for 7-bit-ASCII characters, and apply tolower() only
> >> for character codes above 127. In other words
>
> > If we go this way why not make a special case only and only for 'I'
> > Character and not all 7-bit ASCII:
>
> It seems to me that that's too narrow a definition of the problem.
> I think we should state our goal as "we don't want bizarre locale
> definitions to interfere with downcasing of the basic ASCII letters".
> If we put in a special case for 'I' we will fix the known problem
> with Turkish, but what other strange locales might be out there?
> And if we don't trust tolower() for 'I', why should we trust it
> for 'A'-'Z'?

Since nobody commented on the issue I may suggest a patch that
implements
'I' special case solution. 'A'-'Z' ASCII-only downcasting idea was
rejected
before on basis of SQL99 compliance. I hope I would have more luck with
this
one. Because PostgreSQL just does not work with Turkish locale, and it
was
so since 7.4.0. initdb just chokes on VOID identifier and quits. Devrim
Gunduz will second me on this, I am sure.

With my knowledge of Russian, Arabic and -to some degree- Hebrew
encodings
I claim that this patch will not break them. If someone who uses far
eastern
Encodings would also check it, I think it would be pretty safe to apply
this patch to the source.

Thanks,
Nicolai Tufar