Re: [HACKERS] Postgres 6.5 beta2 and beta3 problem - Mailing list pgsql-hackers

From Oleg Bartunov
Subject Re: [HACKERS] Postgres 6.5 beta2 and beta3 problem
Date
Msg-id Pine.GSO.3.96.SK.990609181726.13133C-100000@ra
Whole thread Raw
In response to Re: [HACKERS] Postgres 6.5 beta2 and beta3 problem  (Daniel Kalchev <daniel@digsys.bg>)
Responses Re: [HACKERS] Postgres 6.5 beta2 and beta3 problem
List pgsql-hackers
On Wed, 9 Jun 1999, Daniel Kalchev wrote:

> Date: Wed, 09 Jun 1999 16:15:58 +0300
> From: Daniel Kalchev <daniel@digsys.bg>
> To: Bruce Momjian <maillist@candle.pha.pa.us>
> Cc: pgsql-hackers@postgreSQL.org
> Subject: Re: [HACKERS] Postgres 6.5 beta2 and beta3 problem 
> 
> Bruce,
> 
> This is extremely bad news, because if will make PostgreSQL 6.5 unusable for 
> most of my applications. Perhaps something can be done to resolve this 
> situation?
> 
> I understand the problem for 16-bit characters support, but for most of the 
> encodings that support only 8 bit characters it should be safe to assume the 
> maximum character value is 255.
> 
> Anyway, making this check compile-time defined would certainly fix things 
> here, because in my case the cyrillic letters order match that of the binary 
> encoding (that is, the first alphabet letter is before the second etc).
> 
> Perhaps the locale data can be used to gather this information?

It's certainly there ! locale data contains all information about
specific character set and encoding. Is it possible to use it to create
indices ? It should be slower but benefits of using indices will cover
expenses for non-US people. I didn't notice such behaivour in Informix
and Oracle. Fixing this would be a good point in respect of popularity
of Postgres. Are there any chance to place it in TODO for 6.6 ?
At least explain should reflect such fact !

Regards,
    Oleg

> 
> I will do some testing without using locale to see what happens.
> 
> Regards,
> Daniel
> 
> >>>Bruce Momjian said:
>  > > Yes,
>  > > 
>  > > I do build with --enable-locale, but I do not build with --enable-mb and d
>      o 
>  > > not use client_encoding or server_encoding.
>  > > 
>  > > The content of the keys is in cyrillic. I have LC_CTYPE=CP1251 in the 
>  > > environment in both server and client, and this has worked for me in 6.4.2
>      .
>  > 
>  > 
>  > This certainly explains it.  With locale enabled, LIKE does not use
>  > indexes because we can't figure out how to do the indexing trick with
>  > non-ASCII character sets because we can't figure out the maximum
>  > character value for a particular encoding.
>  > 
>  > We didn't do the check in 6.4.*, and LIKE was not returning the proper
>  > results for queries at those sites that used locale.
>  > 
>  > -- 
>  >   Bruce Momjian                        |  http://www.op.net/~candle
>  >   maillist@candle.pha.pa.us            |  (610) 853-3000
>  >   +  If your life is a hard drive,     |  830 Blythe Avenue
>  >   +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026
> 
> 
> 

_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] Re: [PORTS] Anyone working on linux Alpha?
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] Postgres 6.5 beta2 and beta3 problem