Capítulo 20. Localização

Sumário
20.1. Suporte a localização
20.1.1. Visão geral
20.1.2. Comportamento
20.1.3. Problemas
20.2. Suporte a conjuntos de caracteres
20.2.1. Conjuntos de caracteres aceitos
20.2.2. Definição do conjunto de caracteres
20.2.3. Conversão automática do conjunto de caracteres entre cliente e servidor
20.2.4. Leitura adicional

Este capítulo descreve as funcionalidades de localização (idioma/país) disponíveis do ponto de vista do administrador. O suporte a localização no PostgreSQL é realizado de duas maneiras:

20.1. Suporte a localização

O suporte a localização se refere a uma aplicação que respeita as preferências culturais com relação ao alfabeto, classificação, formatação de números, etc. O PostgreSQL utiliza as facilidades de localização ISO C e POSIX padrão fornecidas pelo sistema operacional do servidor. Para obter informações adicionais deve ser consultada a documentação do sistema utilizado.

20.1.1. Visão geral

O suporte a localização é inicializado, automaticamente, quando o agrupamento de bancos de dados é criado utilizando o utilitário initdb. Por padrão, o initdb inicializa o agrupamento de bancos de dados com a definição de localização do ambiente onde executa; portanto, se o sistema operacional estiver definido para utilizar a mesma localização desejada para o agrupamento de bancos de dados, então não é necessário ser feito mais nada. Se for desejado utilizar uma localização diferente (ou não houver certeza da localização definida no sistema operacional), pode ser informado ao initdb qual é a localização desejada através da opção --locale. Por exemplo:

initdb --locale=pt_BR

Este exemplo define a localização para Português (pt) conforme falado no Brasil (BR). Outras possibilidades são en_US (Inglês dos Estados Unidos) e fr_CA (Francês do Canadá). Se a localização permitir utilizar mais de um conjunto de caracteres, então a especificação ficará parecida com esta: pt_BR.ISO8859-1. Quais localizações estão disponíveis no sistema operacional, e quais são os seus nomes, depende do que é disponibilizado pelo distribuidor do sistema operacional, e do que foi instalado (Na maioria dos sistemas o comando locale -a mostra a relação de localizações disponíveis).

Ocasionalmente é útil combinar regras diferentes de localização como, por exemplo, regras de classificação do Inglês com mensagens em Português. Para que isto seja possível, existe um conjunto de subcategorias de localização controlando somente certos aspectos das regras de localização.

LC_COLLATE Ordem de classificação das cadeias de caracteres [a] [b]
LC_CTYPE Classificação dos caracteres (O que é uma letra? Sua letra maiúscula equivalente?) [c]
LC_MESSAGES Idioma das mensagens
LC_MONETARY Formatação das quantias monetárias
LC_NUMERIC Formatação dos números
LC_TIME Formatação das datas e das horas
Notas:
a. collation; collating sequence — Um método para comparar duas cadeias de caracteres comparáveis. Todo conjunto de caracteres possui seu collation padrão. (Second Informal Review Draft) ISO/IEC 9075:1992, Database Language SQL- July 30, 1992. (N. do T.)
b. SQL Servercollation: se refere ao conjunto de regras que determinam como os dados são classificados e comparados. Microsoft SQL Server 2000 Introduction - Part No. X05-88268. (N. do T.)
c. LC_CTYPE — Define a classificação do caractere, conversão maiúscula/minúscula, e outros atributos do caractere. LC_CTYPE Category for the Locale Definition Source File Format (N. do T.)
No utilitário initdb os nomes das categorias se traduzem em nomes de opção que mudam a escolha de localização para uma determinada categoria. Por exemplo, para definir a localização como sendo Francês do Canadá, mas utilizar as regras dos E.U.A para formatar valores monetários, deve ser utilizado initdb --locale=fr_CA --lc-monetary=en_US.

Se for desejado que o sistema se comporte como não tendo suporte a localização, devem ser utilizadas as localizações especiais C ou POSIX.

Os valores de algumas categorias de localização devem permanecer fixos por toda a existência do agrupamento de bancos de dados. Ou seja, uma vez executado o utilitário initdb não pode mais haver alteração dos valores definidos para estas categorias. Estas categorias são LC_COLLATE e LC_CTYPE, que afetam a ordem de classificação dos índices e, portanto, devem permanecer fixas ou os índices das colunas de texto vão ficar corrompidos. O PostgreSQL garante que não vai haver alteração registrando os valores de LC_COLLATE e LC_CTYPE usados pelo initdb. O servidor adota estes dois valores, automaticamente, na inicialização.

Quando o servidor está em execução as demais categorias de localização podem ser alteradas como se desejar, definindo as variáveis de configuração em tempo de execução que possuem o mesmo nome das categorias de localização (veja a Seção 16.4 para obter detalhes). Na verdade, os padrões escolhidos pelo utilitário initdb são escritos no arquivo de configuração postgresql.conf apenas para servirem como padrão quando o servidor é inicializado. Se forem removidas as atribuições presentes no arquivo postgresql.conf, o servidor herdará as definições do ambiente de execução.

Deve ser observado que o comportamento de localização do servidor é determinado pelas variáveis de ambiente enxergadas pelo servidor, e não pelo ambiente de qualquer um dos clientes. Portanto, antes de inicializar o servidor deve-se tomar o cuidado de configurar definições de localização corretas. Uma conseqüência deste fato é que, se o cliente e o servidor forem configurados com localizações diferentes, as mensagens poderão ser mostradas em idiomas diferentes dependendo de onde forem originadas.

Nota: Quando se fala em herdar a localização do ambiente de execução, isto significa o seguinte na maioria dos sistemas operacionais: Para uma determinada categoria de localização, como o agrupamento, as seguintes variáveis de ambiente são consultadas, nesta ordem, até ser encontrada uma com valor definido: LC_ALL, LC_COLLATE (a variável correspondente à respectiva categoria) e LANG. Se nenhuma destas variáveis de ambiente estiver definida, então o padrão é utilizar a localização C.

Algumas bibliotecas de localização de mensagem também examinam a variável de ambiente LANGUAGE, que prevalece sobre todas as outras definições de localização para a finalidade de definir o idioma das mensagens. Em caso de dúvida deve ser consultada a documentação do sistema operacional para obter mais informações, em particular a documentação sobre gettext.

Para habilitar as mensagens traduzidas para o idioma preferido do usuário, deve ser habilitado o NLS (suporte a idioma nacional) em tempo de construção. Esta escolha independe dos outros suportes a localização.

20.1.2. Comportamento

O suporte a localização exerce influência sobre as seguintes funcionalidades:

  • Ordem de classificação das consultas que utilizam a cláusula ORDER BY.
  • A família de funções to_char.

O único problema sério na utilização do suporte a localização no PostgreSQL é de desempenho. Por estes motivos a utilização de localização deve ser feita somente quando for realmente necessária.

20.1.3. Problemas

Se apesar do que foi explicado acima o suporte a localização não funcionar, deve ser verificado no sistema operacional se o suporte a localização está configurado de forma correta. Pode ser utilizado o comando locale -a para verificar quais localizações estão instaladas no sistema operacional, caso este comando esteja disponível no sistema operacional utilizado. [1]

Deve ser verificado se o PostgreSQL está realmente utilizando a localização que se pensa que esteja utilizando. As definições de LC_COLLATE e LC_CTYPE são determinadas quando o utilitário initdb é executado, não podendo ser mudadas sem que o initdb seja executado novamente. Outras definições de localização, incluindo LC_MESSAGES e LC_MONETARY, são determinadas inicialmente a partir do ambiente onde o servidor é posto em execução. As definições de LC_COLLATE e LC_CTYPE do banco de dados podem ser verificadas utilizando o programa utilitário pg_controldata.

Na distribuição do código fonte, o diretório src/test/locale contém um conjunto de testes para o suporte a localização do PostgreSQL.

Como é obvio, as aplicações cliente que tratam os erros gerados pelo servidor analisando o texto da mensagem de erro terão problemas quando as mensagens do servidor estiverem em outro idioma. Os autores destas aplicações são aconselhados a utilizar o esquema de códigos de erro para tratar erros, em vez dos textos das mensagens.

A manutenção dos catálogos de mensagens traduzidas requer o esforço contínuo de muitos voluntários que desejam ver o PostgreSQL falando bem o seu idioma. Se as mensagens no seu idioma não estiverem disponíveis atualmente, ou se não estiverem inteiramente traduzidas, sua ajuda será apreciada. Se desejar ajudar, consulte o Capítulo 46 ou escreva para a lista de discussão dos desenvolvedores.

Notas

[1]

O comando locale -a executado no Fedora Core 3 mostrou a seguinte relação: aa_DJ, aa_DJ.iso88591, aa_ER, aa_ER@saaho, aa_ER.utf8, aa_ER.utf8@saaho, aa_ET, aa_ET.utf8, af_ZA, af_ZA.iso88591, ... , portuguese, POSIX, pt_BR, pt_BR.iso88591, pt_BR.utf8, pt_PT, pt_PT@euro, pt_PT.iso88591, pt_PT.iso885915@euro, pt_PT.utf8, ... , zu_ZA, zu_ZA.iso88591, zu_ZA.utf8. (N. do T.)

SourceForge.net Logo