Re: [HACKERS] Postgres 6.5 beta2 and beta3 problem

From: Daniel Kalchev <daniel(at)digsys(dot)bg>
To: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [HACKERS] Postgres 6.5 beta2 and beta3 problem
Date: 1999-06-10 09:05:45
Message-ID: 199906100905.MAA18426@dcave.digsys.bg
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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 the highest 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

Browse pgsql-hackers by date

  From Date Subject
Next Message Oleg Broytmann 1999-06-10 09:13:11 Re: [HACKERS] Postgres 6.5 beta2 and beta3 problem
Previous Message Jan Wieck 1999-06-10 08:44:38 Re: Real Programmers (was: [HACKERS] Priorities for 6.6)