Re: [HACKERS] Postgres 6.5 beta2 and beta3 problem
От | Daniel Kalchev |
---|---|
Тема | Re: [HACKERS] Postgres 6.5 beta2 and beta3 problem |
Дата | |
Msg-id | 199906100905.MAA18426@dcave.digsys.bg обсуждение исходный текст |
Ответ на | Re: [HACKERS] Postgres 6.5 beta2 and beta3 problem (Bruce Momjian <maillist@candle.pha.pa.us>) |
Ответы |
Re: [HACKERS] Postgres 6.5 beta2 and beta3 problem
|
Список | pgsql-hackers |
>>>Bruce Momjian said:> The locale check is near the bottom of parser/gram.y, so you can> certainly enable indexing there. I commented the two ifdefs that had USE_LOCALE in gram.y and now like uses indexes for me... > I am told that french does not have 255 as it's max character, and there> there is no collating interface to request thehighest character. I> suppose one hack would be to go out and test all the char values to see> which is highest. As I understand the current 'non-locale' way the like indexing works, it should create this problem for the Bulgarian cyrillic (cp1251) too, because character code 255 is valid cyrillic character (the last one from the alphabet). Therefore, the solution proposed by Hannu Krosing should be implemented. I believe we can make the assumption, that if you --enable-locale, but do not use --with-mb, then you are using single-byte locales and therefore the hack might work properly. If you use --with-mb you are out of luck until someone explains better how multibyte characters are ordered. Is there other place than gram.y where this hack needs to be implemented? While I am bashing the locale support... why the ~* operator does not work with locales? That is, I need to use construct like SELECT key from t WHERE upper(a) ~ upper('somestring'); instead of SELECT key FROM t WHERE a ~* 'somestring'; Or store everything in the database in uppercase (works for keys) and upper the string in the frontend. The result is that this construct does not use indices. We also cannot create indexes by upper(a). I believe this was outstanding problem in pre-6.4. I found this later problem to be resolved by modifying the backend/regex/makefile to add -funsigned-char to CFLAGS. This is under BSD/OS 4.0.1 - I found out, that by default characters that are 'alpha' in cyrillic are threated by the compiler as negative and therefore isalpha() returns zero... I believe this should be fixed as it may be causing other problems with non-ASCII locales. My proposal is to add -funsigned-char to all places where routines such as 'isalpha' are used, and ifdef it for USE_LOCALE. Daniel
В списке pgsql-hackers по дате отправления: