On 11/27/05, Tom Lane <[EMAIL PROTECTED]> 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. ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
