Olá, continua achando que o problema não é no postgresql... olha só: http://www.nabble.com/Problemas-com-Acentua%C3%A7%C3%A3o.-td15409723.html []'s Luigi Castro Cardeles
2009/4/28 Prof. Benedito A. Cruz <[email protected]> > Resolvemos transferindo os UPPERs e LOWERs para a aplicação, mas ainda > acho que não deveria ser assim. Falha de projeto do PostgreSQL, essas > funções deveriam se comportar de forma diferente dependendo da > codificação de cada banco e não da base toda... > > > Luigi Castro Cardeles escreveu: > > Olá, > > > > esse pode ser seu problema... > > http://archives.postgresql.org//pgsql-bugs/2002-05/msg00138.php > > > > Esse se enquadra mais no solaris (é o que vc usa?) mas mesmo assim o > > título é sugestivo... > > http://mail.nl.linux.org/linux-utf8/2002-10/msg00075.html > > > > []'s > > > > Luigi Castro Cardeles > > > > > > 2009/4/28 Prof. Benedito A. Cruz <[email protected] > > <mailto:[email protected]>> > > > > Onde o UPPER não funciona o initdb usou o padrão do SO que é > > LC_COLLATE = en_US.UTF-8. > > O cliente já testei com UTF8 e LATIN1 acessando este banco e ambos > > dão problema. > > > > Bene > > > > > > Luigi Castro Cardeles escreveu: > >> Olá, > >> > >> essas regras são controladas pelas variáveis LC_COLLATE e > >> LC_CTYPE (que são definidas no initdb). > >> http://www.postgresql.org/docs/8.3/static/sql-createdatabase.html > >> > >> Você tem que tomar cuidado também com a codificação do cliente > >> onde você está digitando... > >> Qual o valor das mesmas no caso onde o upper não retorna o esperado? > >> > >> Luigi Castro Cardeles > >> > >> > >> 2009/4/28 Prof. Benedito A. Cruz <[email protected] > >> <mailto:[email protected]>> > >> > >> Caros > >> > >> Recentemente tive problemas com uma aplicação que > >> funcionava em um > >> banco LATIN1 mas dava problemas em um banco UTF-8. Depois de > >> pesquisar > >> um pouco detectei o seguinte comportamento no PG. > >> > >> 1) Num banco criado como LATIN1: > >> > >> postgres=# \l > >> List of databases > >> Name | Owner | Encoding > >> -----------+-----------+---------- > >> xpto | xxxadm | LATIN1 > >> postgres | postgres | LATIN1 > >> template0 | postgres | LATIN1 > >> template1 | postgres | LATIN1 > >> (4 rows) > >> > >> postgres=# \c xpto > >> You are now connected to database "xpto". > >> xpto=# select UPPER('a'); > >> upper > >> ------- > >> A > >> (1 row) > >> > >> xpto=# select UPPER('á'); > >> upper > >> ------- > >> Á > >> (1 row) > >> > >> 2) Num banco criado como UTF8: > >> > >> postgres=# \l > >> List of databases > >> Name | Owner | Encoding > >> -----------+-----------+---------- > >> xpto | xxxadm | LATIN1 > >> postgres | postgres | UTF8 > >> template0 | postgres | UTF8 > >> template1 | postgres | UTF8 > >> (4 rows) > >> > >> postgres=# \c xpto > >> You are now connected to database "xpto". > >> xpto=# select UPPER('a'); > >> upper > >> ------- > >> A > >> (1 row) > >> > >> xpto=# select UPPER('á'); > >> upper > >> ------- > >> á > >> (1 row) > >> > >> O problema é que no segundo caso a aplicação dá erro porque > >> usa UPPER > >> e LOWER nas queries, que retornam com problemas. O mesmo > >> problema ocorre > >> se o banco "xpto" está em UTF8. A solução foi transferir o > >> UPPER e LOWER > >> para a aplicação e retirar da query. > >> > >> Pergunta: o comportamento dessas funções não deveria seguir o > >> encoding do banco ao qual se está conectado? > >> > >> -- > >> Benedito A. Cruz > >> Centro de Referência em Informação Ambiental - CRIA > >> email [email protected] <mailto:[email protected]> > >> fone 55 19 3288 0466 > >> > >> > >> -- > >> This message has been scanned for viruses and > >> dangerous content by MailScanner, and is > >> believed to be clean. > >> > >> _______________________________________________ > >> pgbr-geral mailing list > >> [email protected] > >> <mailto:[email protected]> > >> > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > >> > >> > >> > >> -- > >> This message has been scanned for viruses and > >> dangerous content by *MailScanner* > >> <http://www.mailscanner.info/>, and is > >> believed to be clean. > >> > ------------------------------------------------------------------------ > >> > >> _______________________________________________ > >> pgbr-geral mailing list > >> [email protected] <mailto: > [email protected]> > >> > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > >> > > > > > > -- > > Benedito A. Cruz > > Centro de Referência em Informação Ambiental - CRIA > > email [email protected] <mailto:[email protected]> > > fone 55 19 3288 0466 > > > > > > -- > > This message has been scanned for viruses and > > dangerous content by *MailScanner* <http://www.mailscanner.info/>, > > and is > > believed to be clean. > > > > _______________________________________________ > > pgbr-geral mailing list > > [email protected] > > <mailto:[email protected]> > > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > > > > > > > > -- > > This message has been scanned for viruses and > > dangerous content by *MailScanner* <http://www.mailscanner.info/>, and > is > > believed to be clean. > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > pgbr-geral mailing list > > [email protected] > > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > > > > > -- > Benedito A. Cruz > Centro de Referência em Informação Ambiental - CRIA > email [email protected] > fone 55 19 3288 0466 > > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > _______________________________________________ > pgbr-geral mailing list > [email protected] > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral >
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
