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

Responder a