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 по дате отправления: