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  (Tatsuo Ishii <t-ishii@sra.co.jp>)
Список 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 по дате отправления:

Предыдущее
От: wieck@debis.com (Jan Wieck)
Дата:
Сообщение: Re: Real Programmers (was: [HACKERS] Priorities for 6.6)
Следующее
От: Oleg Broytmann
Дата:
Сообщение: Re: [HACKERS] Postgres 6.5 beta2 and beta3 problem