Encoding , lc_collate e lc_ctype

LaraW
(usa Outra)

Enviado em 06/03/2017 - 17:11h

Paulo, li tudo que você escreveu e agradeço mais uma vez por toda sua explicação. Falou com bastante propriedade de todos os itens.
Creio que eu estava entendendo esses parâmetros de forma um pouco equivocada.
Só mais algumas dúvidas, se for possível você me esclarecer.

1) Diante de tudo que você colocou, ao escolhar uma locale como C ou POSIX por exemplo, de que forma o banco se comportaria, visto que pelo que entendi em outras documentações esse tipo de locale(C) é o mesmo que não definir nada. Dessa forma ele aceitaria um número que NÃO fosse de 0 a 9 dentro de um campo numerico por exemplo ?

2) Pelo sua explicação, as variaveis que são definidas em locale(lc_ctype, lc_collate, etc) é que dizem respeito ao idioma dos dados que serão preenchidos? O encoding é só uma representação dos caracteres , não tendo nada a ver com idioma?

3) Outra dúvida, você citou collation. Collation e locale são a mesma coisa? Em SQL Server por exemplo, podemos escolher uma collation que não seja sensitiva a acentos e nem a maiúscula e minúscula. No PostgreSQL, tem essa opção?

Grata!!!

paulo1205
(usa Ubuntu)

Enviado em 06/03/2017 - 18:57h

Não. A locale C não habilitaria esse comportamento. Um efeito potencialmente ruim de usar locale C talvez seja a impossibilidade de trabalhar com letras acentuadas.



Não deixa de ter uma certa relação, pois você terá de escolher uma codificação que permita representar os caracteres do idioma escolhido. Não faria muito sentido, por exemplo, definir uma locale como “pt_BR.ASCII”, já que ASCII só usa sete bits, e os caracteres acentuados ocupam posições que precisam de um oitavo bit (a não ser, talvez, se se trabalhar com transliteração com supressão dos acentos, mas aí você perderia as distinções entre maçã, maça e maçã, por exemplo).



Collation é um aspecto de locales.

Eu não tenho conhecimento de BD. Nas locales do UNIX, algumas, tais como C e POSIX, consideram maiúsculas e minúsculas distintas para fins de ordenação, por exemplo, mas dispõem de formas de conversão que permitem fazer busca e ordenação independente de capitalização. Outras locales já trabalham com equivalência entre maiúsculas e minúsculas por padrão, e eventuais distinções teriam de ser tratadas particularmente.

LaraW
(usa Outra)

Enviado em 07/03/2017 - 15:28h

Paulo, muito obrigada por toda sua paciência e suas explicações. Valeu demais!!!!

Vou te fazer uma última pergunta e talvez você possa me responder. Apesar de você dizer que não tem muito conhecimento de banco, mas creio que tem o suficiente.
Talvez alguém também que utilize PostgreSQL no Windows, possa dar sua opinião.

A questão é a seguinte, tenho um banco de dados PostgreSQL 9.3.2 em um servidor Windows 2008 R2 Standard, com base nisso existe uma configuração padrão que seja uma melhor prática para enconding, lc_ctype e lc_collate?

Pergunto isso, porque o banco que tenho lá hoje está da seguinte forma:
enconding = Latin1
lc_ctype = Portuguese_Brazil.1252
lc_collate = Portuguese_Brazil.1252

e ao tentar criar um novo banco com essa configuração, não consigo da forma convencional, pois esse enconding se mostra incompativel com essa locale.
Quando entrei na empresa esse banco já existia assim e os responsáveis não estão aqui mais. Eles criaram da forma convencional e depois foram na pg_database e mudaram o enconding
Como agora essa banco está dando problemas e vamos recria-lo, estou buscando uma melhor configuração.
Com base em toda a sua explicação até cheguei a uma conclusão, mas gostaria de saber a experiencia de vocês.

Desde já agradeço.

paulo1205
(usa Ubuntu)

Enviado em 07/03/2017 - 17:59h

Você tem um banco criado com uma configuração e não consegue criar outro com a mesma configuração? Estranho, mesmo.

Em princípio, “latin1” e Windows-1252 usariam o mesmo encoding, que é usar 8 bits por caráter, mas os dois nomes não são sinônimos. Até onde eu sei, “latin1” é sinônimo de ISO-8859-1, e o WIndows-1252 é uma variante do ISO-8859-1, que substitui caracteres de controle da família ISO-8859 na faixa com índices de 128 a 159 com caracteres gráficos (sinais de pontuação e letras acentuadas ou compostas). Os caracteres do ISO-8859-1 são idênticos aos primeiros 256 caracteres do Unicode; os do Windows-1252 tem de usar um mapeamento para os caracteres nas posições 128 a 159.

Não sei se é por conta desses 32 caracteres que são diferentes que o PostgreSQL não deixou você usar a mesma combinação no banco novo. Qual seria a codificação sugerida pelo banco quando você tenta colocar os demais parâmetros como Windows-1252? Você tem como colocar Windows-1252 também como codificação?