From: | Hannu Krosing <hannu(at)tm(dot)ee> |
---|---|
To: | Rob van Nieuwkerk <robn(at)verdi(dot)et(dot)tudelft(dot)nl> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: 7.0.3 reproduceable serious select error |
Date: | 2001-01-19 10:51:31 |
Message-ID: | 3A681C33.EB384F4B@tm.ee |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Hannu Krosing | 2001-01-19 10:56:25 | Re: 7.0.3 reproduceable serious select error |
Previous Message | Michael Meskes | 2001-01-19 09:28:09 | Re: Changes to include files |