Re: 7.0.3 reproduceable serious select error

Поиск
Список
Период
Сортировка
От Hannu Krosing
Тема Re: 7.0.3 reproduceable serious select error
Дата
Msg-id 3A681C33.EB384F4B@tm.ee
обсуждение исходный текст
Ответ на Re: 7.0.3 reproduceable serious select error  (Rob van Nieuwkerk <robn@verdi.et.tudelft.nl>)
Список pgsql-hackers
Rob van Nieuwkerk wrote:
> 
> 
> The problem query returns the *right* answer now !
> Turning LANG=en_US back on gives the old buggy behaviour.
> 
> I know very little about this LANG, LOCALE etc. stuff.
> But for our application it is very important to support "weird" characters
> like "éőĺĘ ..." etc. for names.  Basically we need all letter symbols
> in ISO-8859-1 (Latin 1).  A quick experiment shows that without the
> LANG setting I can still insert & select strings containing these
> symbols.
> 
> Do I lose any postgresql functionality by just getting rid of the LANG
> environment variable ?  Will I be able to use full ISO-8859-1 in table
> fields without problems ?

You should, except that upper() and lower() will not give you right
answers 
for char>128 and order by orders in ASCII (i.e. character code value)
order.

I would suggest that instead you keep the en_US locale (or some nl
locale 
if you need the rigt ordering from DB), but do _not_ create a b-tree 
(the default) index on your text fields. If you need the index for 
exact lookup (field=const) an hash idex will do fine and i'm pretty sure 
that LIKE optimisations will not use them to spoil searches ;).

-------------------
Hannu


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Zeugswetter Andreas SB
Дата:
Сообщение: AW: AW: AW: AW: AW: AW: Re: tinterval - operator proble ms o n AI X
Следующее
От: Hannu Krosing
Дата:
Сообщение: Re: 7.0.3 reproduceable serious select error