Thread: upper() with LATIN1 problem
Hi, The developers on my company reports me a problem with de upper() function. The problem is: - with a text 'magriñá' - the upper('magriñá') returns MAGRIñà - NOTE that the characters 'ñ' and 'á' didn't change the case. - the text are stored in a table in a character varying(50) field - the database has LATIN1 encoding - the postgresql version is 7.4.7 - the OS is Debian Linux 2.6.10 Please, can anyone help me to resolve this problem? Thanks! -- Guillermo González
=?ISO-8859-1?Q?=22Lic=2E_Guillermo_Gonz=E1lez=22?= <g.gonzalez@cybira.biz> writes: > The problem is: > - with a text 'magri��' > - the upper('magri��') returns MAGRI�� > - NOTE that the characters '�' and '�' didn't change the case. This is determined by your locale (specifically LC_CTYPE) not by what the database thinks the encoding is. You'll probably want to re-initdb in the desired locale. regards, tom lane
Hi, I look at the variable/parameter LC_CTYPE and it is set to C (I think this is the default) for performance reason, the installer says. If I use LATIN1 (spanish) what value is the best option for this variable/parameter? Thanks! -- Guillermo González Tom Lane wrote: > =?ISO-8859-1?Q?=22Lic=2E_Guillermo_Gonz=E1lez=22?= <g.gonzalez@cybira.biz> writes: > >>The problem is: >>- with a text 'magriñá' >>- the upper('magriñá') returns MAGRIñà >>- NOTE that the characters 'ñ' and 'á' didn't change the case. > > > This is determined by your locale (specifically LC_CTYPE) not by what > the database thinks the encoding is. You'll probably want to re-initdb > in the desired locale. > > regards, tom lane >
=?ISO-8859-1?Q?=22Lic=2E_Guillermo_Gonz=E1lez=22?= <g.gonzalez@cybira.biz> writes: > If I use LATIN1 (spanish) what value is the best option for this > variable/parameter? Unfortunately locale names are not all that well standardized. "locale -a" should show you all the names available on your platform. You probably want some variant of "es_ES", the tricky part is figuring out which one uses LATIN1 as opposed to any other encoding. regards, tom lane