Limitações de agrupamentos e diferenças de comportamento - Amazon Aurora

Limitações de agrupamentos e diferenças de comportamento

O Babelfish usa a biblioteca ICU para suporte a agrupamentos. O PostgreSQL é construído com uma versão específica do ICU e pode corresponder no máximo uma versão de um agrupamento. Variações entre versões são inevitáveis, assim como pequenas variações ao longo do tempo à medida que os idiomas evoluem. Na lista a seguir, você pode encontrar algumas limitações conhecidas e variações de comportamento dos agrupamentos do Babelfish:

  • Índices e dependência de tipo de agrupamento: um índice em um tipo definido pelo usuário que depende da biblioteca de agrupamentos International Components for Unicode (ICU) (biblioteca utilizada pelo Babelfish) não é invalidado quando a versão da biblioteca é alterada.

  • Função COLLATIONPROPERTY: propriedades de agrupamento são implementadas apenas para os agrupamentos BBF do Babelfish compatíveis. Para obter mais informações, consulte Babelfish supported collations table.

  • Diferenças de regras de classificação Unicode: agrupamentos SQL para o SQL Server classificam dados codificados em Unicode (nchar e nvarchar) de forma diferente dos dados que não são codificados em Unicode (char e varchar). Os bancos de dados do Babelfish são sempre codificados em UTF-8 e sempre aplicam regras de classificação Unicode de maneira consistente, independentemente do tipo de dados, portanto, a ordem de classificação para char ou varchar é a mesmo que para nchar ou nvarchar.

  • Agrupamentos de igualdade secundária e comportamento da classificação: o agrupamento padrão ICU de igualdade secundária Unicode (CI_AS) classifica sinais de pontuação e outros caracteres não alfanuméricos antes dos caracteres numéricos e os caracteres numéricos antes dos caracteres alfabéticos. No entanto, a ordem de pontuação e outros caracteres especiais é diferente.

  • Agrupamentos terciários, solução alternativa para ORDER BY: agrupamentos SQL, como SQL_Latin1_General_Pref_CP1_CI_AS, são compatíveis com a função TERTIARY_WEIGHTS e a capacidade de classificar strings que se comparam igualmente em um agrupamento CI_AS para classificação inicialmente em maiúsculas: ABC, ABc, AbC, Abc, aBC, aBc, abC e finalmente abc. Assim, a função DENSE_RANK OVER (ORDER BY column) analítica avalia essas strings como tendo a mesma classificação, mas as ordena em maiúsculas primeiro dentro de uma partição.

    Você pode obter um resultado semelhante com o Babelfish adicionando uma cláusula COLLATE à cláusula ORDER BY que especifica um agrupamento CS_AS terciário que especifica @colCaseFirst=upper. No entanto, o modificador colCaseFirst aplica-se somente a strings com igualdade terciária (em vez de igualdade secundária, como um agrupamento CI_AS). Por isso, você não pode emular agrupamentos SQL terciários utilizando um único agrupamento ICU.

    Como solução alternativa, convém aplicações que utilizam o agrupamento SQL_Latin1_General_Pref_CP1_CI_AS de forma a utilizar o agrupamento BBF_SQL_Latin1_General_CP1_CI_AS primeiro. Em seguida, adicione COLLATE BBF_SQL_Latin1_General_Pref_CP1_CS_AS a qualquer cláusula ORDER BY para essa coluna.

  • Expansão de caracteres: uma expansão de caracteres trata um único caractere como igual a uma sequência de caracteres em nível primário. O agrupamento padrão do SQL Server CI_AS é compatível com a expansão de caracteres. Os agrupamentos de ICU são compatíveis com a expansão de caracteres somente para agrupamentos que não distinguem dialetos.

    Quando a expansão de caracteres for necessária, utilize um agrupamento AI para comparações. No entanto, esses agrupamentos atualmente não têm suporte pelo operador LIKE.

  • Codificação char e varchar: quando agrupamentos SQL são utilizados para tipos de dados char ou varchar, a ordem de classificação dos caracteres antes de ASCII 127 é determinada pela página de código específica desse agrupamento SQL. Para agrupamentos SQL, as strings declaradas como char ou varchar podem ser classificadas de maneira diferente de strings declaradas como nchar ou nvarchar.

    O PostgreSQL codifica todas as strings com a codificação do banco de dados, para que todos os caracteres sejam convertidos em UTF-8 e classificados utilizando regras Unicode.

    Como os agrupamentos SQL classificam tipos de dados nchar e nvarchar utilizando regras Unicode, o Babelfish codifica todas as strings no servidor utilizando UTF-8. O Babelfish classifica strings nchar e nvarchar da mesma maneira que classifica strings char e varchar, utilizando regras Unicode.

  • Caractere suplementar: as funções do SQL Server NCHAR, UNICODE e LEN são compatíveis com caracteres para pontos de código fora do Unicode Basic Multilingual Plane (BMP). Em contraste, agrupamentos não SC utilizam caracteres de pares substitutos para lidar com caracteres suplementares. Para tipos de dados Unicode, o SQL Server pode representar até 65.535 caracteres utilizando UCS-2 ou o intervalo Unicode completo (1.114.111 caracteres) se forem utilizados caracteres suplementares.

  • Agrupamentos que fazem distinção do Kana (KS): um agrupamento que faz distinção do Kana (KS) é aquele que trata caracteres Kana japoneses Hiragana e Katakana de forma diferente. O ICU é compatível com o padrão de agrupamento japonês JIS X 4061. O agora obsoleto modificador de localidade colhiraganaQ [on | off] pode fornecer a mesma funcionalidade que agrupamentos KS. No entanto, agrupamentos KS com o mesmo nome que os do SQL Server atualmente não têm suporte pelo Babelfish.

  • Agrupamentos sensíveis à largura (WS): quando um caractere de byte único (meia largura) e o mesmo caractere representado como um caractere de byte duplo (largura total) são tratados de maneiras diferentes, o agrupamento é chamado de sensível à largura (WS). Agrupamentos WS com o mesmo nome que os do SQL Server atualmente não têm suporte pelo Babelfish.

  • Agrupamentos que fazem distinção do seletor de variação (VSS): agrupamentos que fazem distinção do seletor de variação (VSS) distinguem entre seletores de variação ideográfica em agrupamentos Japanese_Bushu_Kakusu_140 e Japanese_XJIS_140 do japonês. Uma sequência de variação é composta por um caractere base mais um seletor de variação adicional. Se você não selecionar a opção _VSS, o seletor de variação não será considerado na comparação.

    Atualmente, agrupamentos VSS não têm suporte pelo Babelfish.

  • Agrupamentos BIN e BIN2: um agrupamento BIN2 classifica os caracteres de acordo com a ordem de pontos de código. A ordem binária byte a byte do UTF-8 preserva a ordem dos pontos de código Unicode e, portanto, é provável que esse também seja o agrupamento com a melhor performance. Se a ordem de pontos de código Unicode funcionar para uma aplicação, considere utilizar um agrupamento BIN2. No entanto, o uso de um agrupamento BIN2 pode resultar na exibição de dados no cliente em uma ordem culturalmente inesperada. Como novos mapeamentos para caracteres em minúsculas são adicionados ao Unicode com o passar do tempo, a função LOWER pode operar de maneira diferente em diferentes versões do ICU. Esse é um caso especial do problema mais geral de versionamento de agrupamentos, e não algo específico do agrupamento BIN2.

    O Babelfish fornece o agrupamento BBF_Latin1_General_BIN2 com a distribuição do Babelfish para agrupar em ordem de pontos de código Unicode. Em um agrupamento BIN, somente o primeiro caractere é classificado como um wchar. Os caracteres restantes são classificados byte a byte, efetivamente na ordem de pontos de código, de acordo com a codificação. Essa abordagem não segue regras de agrupamento Unicode e não tem suporte pelo Babelfish.

  • Agrupamentos não determinísticos e limitação CHARINDEX: para versões do Babelfish anteriores à versão 2.1.0, você não pode usar CHARINDEX com agrupamentos não determinísticos. Por padrão, o Babelfish usa um agrupamento que não faz distinção de maiúsculas e minúsculas (não determinístico). Usar CHARINDEX para versões anteriores do Babelfish gera o seguinte erro de tempo de execução:

    nondeterministic collations are not supported for substring searches
    nota

    Essa limitação e solução alternativa se aplicam somente ao Babelfish versão 1.x (versões 13.x do Aurora PostgreSQL). O Babelfish 2.1.0 e versões posteriores não têm esse problema.

    Para contornar este problema, execute um dos seguintes procedimentos:

    • Converta explicitamente a expressão em um agrupamento que diferencie letras maiúsculas de minúsculas e deixe em minúsculas ambos os argumentos aplicando LOWER ou UPPER. Por exemplo, SELECT charindex('x', a) FROM t1 transforma-se no seguinte:

      SELECT charindex(LOWER('x'), LOWER(a COLLATE sql_latin1_general_cp1_cs_as)) FROM t1

    • Crie a função f_charindex do SQL e substitua chamadas CHARINDEX por chamadas para a seguinte função:

      CREATE function f_charindex(@s1 varchar(max), @s2 varchar(max)) RETURNS int
AS
BEGIN
declare @i int = 1
WHILE len(@s2) >= len(@s1)
BEGIN
  if LOWER(@s1) = LOWER(substring(@s2,1,len(@s1))) return @i
  set @i += 1
  set @s2 = substring(@s2,2,999999999)
END
return 0
END
go