On 11/27/05, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > Yes, indeed. I agree with you to find a proper solution for character
> > set handling. But, IMHO, it's better to have a-patchy working system
> > instead of a not working one.
>
> But you just agreed that it doesn't work.
You get me wrong. I tried to to say it works for latin5 and unicode.
When I look at the latin-n implementation of PostgreSQL, see that
there doesn't exist a far difference between 'em. So there shouldn't
be a problem with latin-n encodings. But, as I try to explain, I don't
have so much knowledge on unicode characters and cannot claim an exact
answer about it.
> It might be that there are degrees of not-working-ness here, but before
> adopting a partial solution I would like to see some reasoning why it
> won't make things worse for other people. I think that what you are
> proposing could lead to arbitrarily bad behavior (up to and including
> server crashes) depending on what libc's toupper/tolower functions are
> coded to do with out-of-range inputs.
Furthermore, I just used the methods already in the code. If it'll
cause any crashes in the server side, it won't be my fault. (Except
logical errors I made.)
> Exactly what cases have you tried, and on what platforms?
I don't have a buildfarm at home. Tests made on an i686 with a
2.6.12.5 kernel. Here's a short list of cases I tried with both latin5
and unicode charsets:
- lower/upper functions with Turkish characters.
- ILIKE matches with both lower and upper case Turkish characters.
(Above testes succeeded for non-Turkish characters too.)
Regards.