Re: Problema ILIKE con letra eñe

Hola a todos los miembros de la lista.

Tengo un problema con respecto al ILIKE pero solo con la letra eñe.
Anteriormente ya tenía problemas con la eñe pero lo solucioné al crear
la BD con enconding = LATIN1.

El ejemplo es el siguiente:

CREATE TABLE PERSONA (
idPersona SERIAL NOT NULL,
nombres TEXT NULL,
apPaterno TEXT NULL,
apMaterno TEXT NULL,
PRIMARY KEY (idPersona)
);

insert into PERSONA values ( DEFAULT , 'juaN' , 'muÑante' , 'ruiZ' );

Cuando se quiere hacer las siguientes consultas :

1) select * from persona
where apPaterno ILIKE 'muñante' ;

se obtiene 0 lineas

2) select * from persona
where apPaterno ILIKE 'MUÑANTE' ;

se obtiene la unica linea insertada

3) select * from persona
where apPaterno ILIKE 'muÑante' ;

se obtiene la unica linea insertada

Los resultados son iguales en potgres 7.4 con cygwin en windows , asi
como en postgres 8.1.3 en windows XP.

Alguna idea de por que solo la eñe se escapa del ILIKE ???

Gracias por anticipado por sus posibles respuestas.

Paolo.

Paolo Lopez escribió:
> Hola a todos los miembros de la lista.
>
> Tengo un problema con respecto al ILIKE pero solo con la letra eñe.
> Anteriormente ya tenía problemas con la eñe pero lo solucioné al crear
> la BD con enconding = LATIN1.

Muestra lo que retorna lo siguiente:

select upper('muñoz');

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

No puedo ingresar el caracter eñe desde linea de comandos de windows,
salen caracteres extraños : + para eñe minuscula y D para eñe
mayuscula.

Envio el resultado generado en pgadmin:

select upper('muñoz');

resultado : "MUñOZ"

On 4/21/06, Alvaro Herrera <alvherre(at)commandprompt(dot)com> wrote:
> Paolo Lopez escribió:
> > Hola a todos los miembros de la lista.
> >
> > Tengo un problema con respecto al ILIKE pero solo con la letra eñe.
> > Anteriormente ya tenía problemas con la eñe pero lo solucioné al crear
> > la BD con enconding = LATIN1.
>
> Muestra lo que retorna lo siguiente:
>
> select upper('muñoz');
>
> --
> Alvaro Herrera http://www.CommandPrompt.com/
> The PostgreSQL Company - Command Prompt, Inc.
>

Paolo Lopez escribió:
> No puedo ingresar el caracter eñe desde linea de comandos de windows,
> salen caracteres extraños : + para eñe minuscula y D para eñe
> mayuscula.
>
> Envio el resultado generado en pgadmin:
>
> select upper('muñoz');
>
> resultado : "MUñOZ"

Uff. Define el client_encoding correcto ... probablemente pgAdmin3 esta
usando un juego de caracteres que no es el mismo latin1 que tiene el
servidor.

Yo creo que ambas cosas estan relacionadas: el que la ñ no se convierta
a mayusculas, y el que salgan "caracteres raros" cuando los ingresas en
la linea de comandos.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

On 4/21/06, Paolo Lopez <murphyperu(at)gmail(dot)com> wrote:
> Hola a todos los miembros de la lista.
>
> Tengo un problema con respecto al ILIKE pero solo con la letra eñe.
> Anteriormente ya tenía problemas con la eñe pero lo solucioné al crear
> la BD con enconding = LATIN1.
>
> El ejemplo es el siguiente:
>
> CREATE TABLE PERSONA (
> idPersona SERIAL NOT NULL,
> nombres TEXT NULL,
> apPaterno TEXT NULL,
> apMaterno TEXT NULL,
> PRIMARY KEY (idPersona)
> );
>
> insert into PERSONA values ( DEFAULT , 'juaN' , 'muÑante' , 'ruiZ' );
>
>
> Cuando se quiere hacer las siguientes consultas :
>
> 1) select * from persona
> where apPaterno ILIKE 'muñante' ;
>
> se obtiene 0 lineas
>
>
> 2) select * from persona
> where apPaterno ILIKE 'MUÑANTE' ;
>
> se obtiene la unica linea insertada
>
>
> 3) select * from persona
> where apPaterno ILIKE 'muÑante' ;
>
> se obtiene la unica linea insertada
>
>
> Los resultados son iguales en potgres 7.4 con cygwin en windows , asi
> como en postgres 8.1.3 en windows XP.
>
>
> Alguna idea de por que solo la eñe se escapa del ILIKE ???
>
>

no puedo reproducir tu problema, los 3 selects muestran la fila ingresada.
windows xp
postgresql-8.1.3

database encoding latin1 aunque no tengo idea de cual sera el client_encoding

--
Atentamente,
Jaime Casanova

"What they (MySQL) lose in usability, they gain back in benchmarks, and that's
all that matters: getting the wrong answer really fast."
Randal L. Schwartz

Jaime: Gracias por probar el ejemplo, pero los resultados del select
los obtuviste desde linea de comandos o por el pgadmin ??

prueba con

show client_encoding;

desde linea de comandos y pgadmin para saber tu client_encoding.

Alvaro: Mi client_encoding me sale UNICODE desde pgadmin y LATIN1
desde linea de comandos. Pero igual no se puede hacer upper de la
letra eñe en ninguno de los 2 escenarios.

Paolo.

On 4/21/06, Jaime Casanova <systemguards(at)gmail(dot)com> wrote:
> On 4/21/06, Paolo Lopez <murphyperu(at)gmail(dot)com> wrote:
> > Hola a todos los miembros de la lista.
> >
> > Tengo un problema con respecto al ILIKE pero solo con la letra eñe.
> > Anteriormente ya tenía problemas con la eñe pero lo solucioné al crear
> > la BD con enconding = LATIN1.
> >
> > El ejemplo es el siguiente:
> >
> > CREATE TABLE PERSONA (
> > idPersona SERIAL NOT NULL,
> > nombres TEXT NULL,
> > apPaterno TEXT NULL,
> > apMaterno TEXT NULL,
> > PRIMARY KEY (idPersona)
> > );
> >
> > insert into PERSONA values ( DEFAULT , 'juaN' , 'muÑante' , 'ruiZ' );
> >
> >
> > Cuando se quiere hacer las siguientes consultas :
> >
> > 1) select * from persona
> > where apPaterno ILIKE 'muñante' ;
> >
> > se obtiene 0 lineas
> >
> >
> > 2) select * from persona
> > where apPaterno ILIKE 'MUÑANTE' ;
> >
> > se obtiene la unica linea insertada
> >
> >
> > 3) select * from persona
> > where apPaterno ILIKE 'muÑante' ;
> >
> > se obtiene la unica linea insertada
> >
> >
> > Los resultados son iguales en potgres 7.4 con cygwin en windows , asi
> > como en postgres 8.1.3 en windows XP.
> >
> >
> > Alguna idea de por que solo la eñe se escapa del ILIKE ???
> >
> >
>
> no puedo reproducir tu problema, los 3 selects muestran la fila ingresada.
> windows xp
> postgresql-8.1.3
>
> database encoding latin1 aunque no tengo idea de cual sera el client_encoding
>
> --
> Atentamente,
> Jaime Casanova
>
> "What they (MySQL) lose in usability, they gain back in benchmarks, and that's
> all that matters: getting the wrong answer really fast."
> Randal L. Schwartz
>

On 4/22/06, Paolo Lopez <murphyperu(at)gmail(dot)com> wrote:
> Jaime: Gracias por probar el ejemplo, pero los resultados del select
> los obtuviste desde linea de comandos o por el pgadmin ??
>

me declarare culpable, hice las pruebas con el pgAdmin

rehaciendo las pruebas en psql ninguno de los 3 selects devuelve la fila...

y al ver la fila desde el psql, la muestra asi:

prueba=# select * from persona;
idpersona | nombres | appaterno | apmaterno
-----------+---------+-----------+-----------
1 | juaN | muÐante | ruiZ
(1 fila)

claro que el dato lo ingrese desde el pgAdmin, pero no deberia haber
hecho recodificacion de UNICODE a LATIN1 para guardarlo en la base?

server_encoding: LATIN1
client_encoding en psql: LATIN1
client_encoding en pgAdmin: UNICODE

al actualizar la fila con la letra ñ grabada desde el psql, reproduzco
el error de Paolo en el que ILIKE considera diferentes a 'ñ' y 'Ñ'

> prueba con
>
> show client_encoding;
>
> desde linea de comandos y pgadmin para saber tu client_encoding.
>

parezco novato, verdad?

asi que en teoria en el psql deberia tener garantizado que salga bien

>
> Alvaro: Mi client_encoding me sale UNICODE desde pgadmin y LATIN1
> desde linea de comandos. Pero igual no se puede hacer upper de la
> letra eñe en ninguno de los 2 escenarios.
>
>

ni upper ni lower, sin embargo el problema lo veo exclusivamente en
psql (LATIN1 a LATIN1)

prueba:

select lower('Ñ');
select upper('ñ');

en ambos lados

--
Atentamente,
Jaime Casanova

"What they (MySQL) lose in usability, they gain back in benchmarks, and that's
all that matters: getting the wrong answer really fast."
Randal L. Schwartz

Jaime Casanova escribió:
> On 4/22/06, Paolo Lopez <murphyperu(at)gmail(dot)com> wrote:
> > Jaime: Gracias por probar el ejemplo, pero los resultados del select
> > los obtuviste desde linea de comandos o por el pgadmin ??
> >
>
> me declarare culpable, hice las pruebas con el pgAdmin
>
> rehaciendo las pruebas en psql ninguno de los 3 selects devuelve la fila...
>
> y al ver la fila desde el psql, la muestra asi:
>
> prueba=# select * from persona;
> idpersona | nombres | appaterno | apmaterno
> -----------+---------+-----------+-----------
> 1 | juaN | muÐante | ruiZ
> (1 fila)

Ojo! El client_encoding tiene que estar definido correctamente en ambos
casos, tanto al ingresar la tupla como al extraerla. Para que el
upper() funcione correctamente, lo importante es que el ingreso haya
sido correcto.

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

On 4/22/06, Alvaro Herrera <alvherre(at)commandprompt(dot)com> wrote:
> Jaime Casanova escribió:
> > On 4/22/06, Paolo Lopez <murphyperu(at)gmail(dot)com> wrote:
> > > Jaime: Gracias por probar el ejemplo, pero los resultados del select
> > > los obtuviste desde linea de comandos o por el pgadmin ??
> > >
> >
> > me declarare culpable, hice las pruebas con el pgAdmin
> >
> > rehaciendo las pruebas en psql ninguno de los 3 selects devuelve la fila...
> >
> > y al ver la fila desde el psql, la muestra asi:
> >
> > prueba=# select * from persona;
> > idpersona | nombres | appaterno | apmaterno
> > -----------+---------+-----------+-----------
> > 1 | juaN | muÐante | ruiZ
> > (1 fila)
>
> Ojo! El client_encoding tiene que estar definido correctamente en ambos
> casos, tanto al ingresar la tupla como al extraerla. Para que el
> upper() funcione correctamente, lo importante es que el ingreso haya
> sido correcto.
>
> --
> Alvaro Herrera http://www.CommandPrompt.com/
> PostgreSQL Replication, Consulting, Custom Development, 24x7 support
>

Lo se...

prueba=# insert into persona values (default, 'Alicia', 'Oñate', 'nose');
INSERT 0 1
prueba=# select * from persona where appaterno ILIKE 'OÑATE';
idpersona | nombres | appaterno | apmaterno
-----------+---------+-----------+-----------
(0 filas)

prueba=# select * from persona where appaterno ILIKE 'OñATE';
idpersona | nombres | appaterno | apmaterno
-----------+---------+-----------+-----------
2 | Alicia | Oñate | nose
(1 fila)

prueba=# select * from persona where lower(appaterno) LIKE lower('OÑATE');
idpersona | nombres | appaterno | apmaterno
-----------+---------+-----------+-----------
(0 filas)

prueba=# show server_encoding;
server_encoding
-----------------
LATIN1
(1 fila)

prueba=# show client_encoding;
client_encoding
-----------------
LATIN1
(1 fila)

prueba=# \l
Listado de base de datos
Nombre | Due±o | Codificaci¾n
-----------+----------+--------------
bench | postgres | LATIN1
postgres | postgres | LATIN1
prueba | postgres | LATIN1
template0 | postgres | LATIN1
template1 | postgres | LATIN1
(5 filas)

de todos modos desconfio por la forma en que se muestran caracteres latinos...

quiza tenga que ver con el locale?
el locale que estoy usando es uno propio de windows Spanish_Ecuador.28591

e internamente el acceso directo al psql establece el codigo de pagina
1252... no se si algo de esto servira

--
Atentamente,
Jaime Casanova

"What they (MySQL) lose in usability, they gain back in benchmarks, and that's
all that matters: getting the wrong answer really fast."
Randal L. Schwartz

Jaime Casanova escribió:

> e internamente el acceso directo al psql establece el codigo de pagina
> 1252... no se si algo de esto servira

Que pasa si haces un SET client_encoding TO win1252?

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

En mi caso desde el psql obtengo lo siguiente :

prueba=# show server_encoding;
server_encoding
-----------------
LATIN1
(1 row)

prueba=# show client_encoding;
client_encoding
-----------------
LATIN1
(1 row)

prueba=# \l
List of databases
Name | Owner | Encoding
----------------------+--------+-----------
Paul | IRVINE | LATIN1
postgres | IRVINE | SQL_ASCII
prueba | IRVINE | LATIN1
template0 | IRVINE | SQL_ASCII
template1 | IRVINE | SQL_ASCII
(5 rows)

El problema me parece no es en como se guarda los datos ya que
AFIRMATIVAMENTE se guarda los caracteres eñe minuscula o mayuscula, el
problema esta en las funciones upper y lower solo para ese caracter.

Leyendo los manuales del postgres en pgadmin, en el capitulo

21.1. Locale Support

dice lo siguiente :

21.1.2. Behavior
The locale settings influence the following SQL features:

Sort order in queries using ORDER BY on textual data

The ability to use indexes with LIKE clauses

The upper, lower, and initcap functions

The to_char family of functions

Ademas de que tambien he leido ( no recuerdo en este momento ) que el
locale C es el mas estable a manera generica.

En mi caso obtengo lo siguiente :

prueba=# show LC_COLLATE;
lc_collate
------------
C
(1 row)

prueba=# show LC_CTYPE;
lc_ctype
----------
C
(1 row)

Alguna idea de lo del LOCALE ?? puede ser este el problema ??

Alvaro : he probado lo que sugieres y me sale lo siguiente :

prueba=# SET client_encoding TO win1252;
ERROR: conversion between win1252 and LATIN1 is not supported

Paolo.

On 4/22/06, Alvaro Herrera <alvherre(at)commandprompt(dot)com> wrote:
> Jaime Casanova escribió:
>
> > e internamente el acceso directo al psql establece el codigo de pagina
> > 1252... no se si algo de esto servira
>
> Que pasa si haces un SET client_encoding TO win1252?
>
> --
> Alvaro Herrera http://www.CommandPrompt.com/
> The PostgreSQL Company - Command Prompt, Inc.
>

Paolo Lopez escribió:

> El problema me parece no es en como se guarda los datos ya que
> AFIRMATIVAMENTE se guarda los caracteres eñe minuscula o mayuscula, el
> problema esta en las funciones upper y lower solo para ese caracter.

Ja. Si fuera tan simple, el problema ya estaria resuelto.

Me sorprende que no se pueda hacer conversion entre win1252 y Latin1.
Estuve mirando las definiciones en
http://www.microsoft.com/globaldev/reference/iso/28591.mspx
(iso-8859-1, a.k.a. Latin-1)

y
http://www.microsoft.com/globaldev/reference/sbcs/1252.mspx
(Win1252)

y se ven bastante equivalentes.

Yo personalmente nunca he tenido problemas con esto porque no uso
Windows, pero los afectados podrian hacer un analisis mas exhaustivo.
Este empieza por entender que simplemente pegando en el email el
"caracter raro" otra persona no tiene como saber lo que esta pasando.
La informacion tiene que venir de una forma que no sufra reconversion de
caracteres. Por ejemplo "en vez de la eñe viene una letra que parece
una yuxtaposición de una D con una E".

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

On 4/22/06, Alvaro Herrera <alvherre(at)commandprompt(dot)com> wrote:
> Paolo Lopez escribió:
>
> > El problema me parece no es en como se guarda los datos ya que
> > AFIRMATIVAMENTE se guarda los caracteres eñe minuscula o mayuscula, el
> > problema esta en las funciones upper y lower solo para ese caracter.
>
> Ja. Si fuera tan simple, el problema ya estaria resuelto.
>
> Me sorprende que no se pueda hacer conversion entre win1252 y Latin1.
> Estuve mirando las definiciones en
> http://www.microsoft.com/globaldev/reference/iso/28591.mspx
> (iso-8859-1, a.k.a. Latin-1)
>
> y
> http://www.microsoft.com/globaldev/reference/sbcs/1252.mspx
> (Win1252)
>
> y se ven bastante equivalentes.
>

voy a mirar un poco esos enlaces para ver si saco algo en claro...

> Yo personalmente nunca he tenido problemas con esto porque no uso
> Windows, pero los afectados podrian hacer un analisis mas exhaustivo.
> Este empieza por entender que simplemente pegando en el email el
> "caracter raro" otra persona no tiene como saber lo que esta pasando.
> La informacion tiene que venir de una forma que no sufra reconversion de
> caracteres. Por ejemplo "en vez de la eñe viene una letra que parece
> una yuxtaposición de una D con una E".
>

exactamente el mismo caracter que me muestra cuando inserto en el
pgAdmin3 y lo selecciono desde el psql

por ahora no me ha afectado porque de todos modos siempre trabajo
desde el pgAdmin3 o vb...

--
Atentamente,
Jaime Casanova

"What they (MySQL) lose in usability, they gain back in benchmarks, and that's
all that matters: getting the wrong answer really fast."
Randal L. Schwartz

Jaime Casanova escribió:
> On 4/22/06, Alvaro Herrera <alvherre(at)commandprompt(dot)com> wrote:

> > Yo personalmente nunca he tenido problemas con esto porque no uso
> > Windows, pero los afectados podrian hacer un analisis mas exhaustivo.
> > Este empieza por entender que simplemente pegando en el email el
> > "caracter raro" otra persona no tiene como saber lo que esta pasando.
> > La informacion tiene que venir de una forma que no sufra reconversion de
> > caracteres. Por ejemplo "en vez de la eñe viene una letra que parece
> > una yuxtaposición de una D con una E".
>
> exactamente el mismo caracter que me muestra cuando inserto en el
> pgAdmin3 y lo selecciono desde el psql

Interesante. Observa que en el CP "OEM 850"[1], el byte D1 representa
el caracter Unicode "U+00D0" (LATIN CAPITAL LETTER ETH), mientras que en
iso-8859-1[2] el byte D1 representa U+00D1 (LATIN CAPITAL LETTER N WITH
TILDE).

Por lo tanto me atrevo a afirmar que lo que sucede es que uno de los dos
programas esta usando cp850 (probablemente pgAdmin3) y el otro Latin1,
pero no estan declarados correctamente en el client_encoding.

Ahora, se me ocurre que cp850 no esta soportado como charset en
Postgres ...

[1] http://www.microsoft.com/globaldev/reference/oem/850.mspx
[2] http://www.microsoft.com/globaldev/reference/iso/28591.mspx

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

He estado haciendo algunas pruebas para ver si es que el problema del
ILIKE , UPPER y LOWER tienen que ver con el LOCALE y no con el
server_encoding y client_encoding.

Durante la instalacion de la version 8.1.3 para windows al momento de
pedirme los datos en initdb antes seleccionaba LOCALE = C , ahora lo
he cambiado por LOCALE = Spanish_Peru.

Corriendo el ejemplo que he publicado antes:

CREATE TABLE PERSONA (
idPersona SERIAL NOT NULL,
nombres TEXT NULL,
apPaterno TEXT NULL,
apMaterno TEXT NULL,
PRIMARY KEY (idPersona)
);

insert into PERSONA values ( DEFAULT , 'juaN' , 'muÑante' , 'ruiZ' );

para las consultas:

select * from persona
where apPaterno ILIKE 'muñante' ;

select * from persona
where apPaterno ILIKE 'MUÑANTE' ;

select * from persona
where apPaterno ILIKE 'muÑante' ;

me esta arrojando ahora si el resultado correcto que es la unica linea
de la tabla.

Jaime: He tratado de reproducir tu ejemplo y con tu LOCALE =
Spanish_Ecuador y no he tenido los problemas que dices.

>
> prueba=# insert into persona values (default, 'Alicia', 'Oñate', 'nose');
> INSERT 0 1
> prueba=# select * from persona where appaterno ILIKE 'OÑATE';
> idpersona | nombres | appaterno | apmaterno
> -----------+---------+-----------+-----------
> (0 filas)
>
> prueba=# select * from persona where appaterno ILIKE 'OñATE';
> idpersona | nombres | appaterno | apmaterno
> -----------+---------+-----------+-----------
> 2 | Alicia | Oñate | nose
> (1 fila)
>
> prueba=# select * from persona where lower(appaterno) LIKE lower('OÑATE');
> idpersona | nombres | appaterno | apmaterno
> -----------+---------+-----------+-----------
> (0 filas)
>

Ademas probando tu ejemplo para mi LOCALE = Spanish_Peru los
resultados que se obtienen tambien son correctos.

Otra cosa que he encontado durante las pruebas que he efectuado. Al
momento de instalar postgres en windows, cuando se me pide los datos
en initdb, intenté:

1) LOCALE = C
SERVER ENCONDIG = UTF8

el show lc_collate devuelve C

2) LOCALE = C
SERVER ENCONDIG = Latin1

el show lc_collate devuelve C

3) LOCALE = Spanish_Peru
SERVER ENCONDIG = UTF8

el show lc_collate devuelve Spanish_Mexico.1252

4) LOCALE = Spanish_Peru
SERVER ENCONDIG = Latin1

el show lc_collate devuelve Spanish_Peru.28591

5) LOCALE = Greek
SERVER ENCONDIG = UTF8

el show lc_collate devuelve Spanish_Mexico.1252

6) LOCALE = Spanish_Ecuador
SERVER ENCONDIG = Latin1

el show lc_collate devuelve Spanish_Ecuador.28591

Para 1) y 2) siempre "show lc_collate" devuelve C, pero he notado que
de 3) a 6) si se escoge SERVER ENCONDIG = UTF8 me devuelve "show
lc_collate" el codigo de mi windows que es Spanish_Mexico.1252, pero
cuando se escoge SERVER ENCONDIG = Latin1 siempre "show lc_collate"
devuelve LOCALE_ELEGIDO.28591
Alguien sabe el porque de este comportamiento ???

Hasta el momento LOCALE = C durante la instalacion parece ser el
problema para ILIKE , UPPER y LOWER, pero por favor intenten ustedes
para las comprobaciones correspondientes.

Paolo.