ATUALIZAÇÃO : depois de initdb
entrar em contato com libc
o provedor local (em vez de icu
), começou a funcionar bem. Isso é um bug ou a UTI simplesmente atribui outra coisa a "C"?
Eu criei um banco de dados explicitamente com:
encoding = 'utf8'
lc_collate = 'C'
lc_ctype = 'en_US.utf8'
E show lc_collate
shows C
. Mas ao comparar strings, é outra coisa:
select 'B' > 'a';
> true
select 'B' collate "C" > 'a' collate "C";
> false
Por quê? Os valores em minhas colunas também são classificados incorretamente, a menos que eu diga explicitamente para usar "C".
Ambiente: MacOS, PGv15. Meu cluster foi inicializado com o ICU habilitado.
P: A UTI simplesmente atribui outra coisa a "C"
"C" como um nome de localidade refere-se a uma localidade integrada na libc, mas na verdade não significa nada para o ICU.
Se você tivesse passado "C" no
ICU_LOCALE
argumento,CREATE DATABASE
ele teria sido essencialmente ignorado e interpretado como "idioma não especificado".O objetivo de passar algo no
lc_collate
argumento de um banco de dados cujo provedor de localidadeICU
é definir a variável de ambienteLC_COLLATE
para esse valor. Pode ser útil para código em extensões, especialmente em linguagens PL, que chamam funções como strcoll ou strxfrm . Mas as comparações de string iniciadas pelo próprio Postgres com o agrupamento ICU padrão não usarão o que está nolc_collate
parâmetro do banco de dados. É por isso que definirlc_collate
comoC
não tem efeito em seu novo banco de dados.Para criar um banco de dados com C como agrupamento padrão, em um cluster inicializado com ICU como padrão, ele deve ser um
libc
banco de dados e criado a partirtemplate0
de uma instrução como: