Re: Case Conversion Fix for MB Chars
От | Volkan YAZICI |
---|---|
Тема | Re: Case Conversion Fix for MB Chars |
Дата | |
Msg-id | 7104a7370511271347g699a2dcat89b692bd9ad815e3@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Case Conversion Fix for MB Chars (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Case Conversion Fix for MB Chars
|
Список | pgsql-patches |
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.
В списке pgsql-patches по дате отправления: