Limitaciones de intercalación y diferencias de comportamiento - Amazon Aurora

Limitaciones de intercalación y diferencias de comportamiento

Babelfish utiliza la biblioteca de ICU para admitir la intercalación. PostgreSQL se creó con una versión específica de ICU y puede coincidir como máximo con una versión de una intercalación. Las variaciones entre versiones son inevitables, al igual que las variaciones menores en el tiempo a medida que evolucionan los lenguajes. En la siguiente lista puede encontrar las limitaciones conocidas y las variaciones de comportamiento de las intercalaciones de Babelfish:

  • Índices y dependencia del tipo de intercalación: un índice de un tipo definido por el usuario que depende de la biblioteca de intercalación de Componentes internacionales para Unicode (ICU), la biblioteca utilizada por Babelfish, no se invalida cuando se cambia la versión de la biblioteca.

  • Función COLLATIONPROPERTY: las propiedades de intercalación solo se implementan para las intercalaciones de BBF admitidas de Babelfish. Para obtener más información, consulte la Babelfish supported collations table.

  • Diferencias de las reglas de orden de Unicode: las intercalaciones de SQL Server ordenan los datos codificados en Unicode (nchar y nvarchar) de una manera distinta a los datos que no están codificados en Unicode (char y varchar). Las bases de datos de Babelfish siempre están codificadas en UTF-8 y siempre aplican reglas de orden Unicode de manera coherente, independientemente del tipo de datos, por lo que el orden de clasificación para char o varchar es el mismo que para nchar o nvarchar.

  • Intercalaciones secundarias iguales y comportamiento de orden: la intercalación secundaria de igualdad Unicode de ICU predeterminada (CI_AS) ordena los signos de puntuación y otros caracteres no alfanuméricos antes que los caracteres numéricos y los caracteres numéricos antes que los caracteres alfabéticos. Sin embargo, el orden de puntuación y otros caracteres especiales son diferentes.

  • Intercalaciones terciarias, solución para ORDER BY: las intercalaciones de SQL, tales como SQL_Latin1_General_Pref_CP1_CI_AS, admiten la función TERTIARY_WEIGHTS y la capacidad de ordenar cadenas que se comparan por igual en una intercalación CI_AS que debe ordenarse en mayúsculas primero: ABC, ABc, AbC, Abc, aBC, aBc, abC y, por último, abc. Por lo tanto, la función de análisis DENSE_RANK OVER (ORDER BY column) evalúa estas cadenas como del mismo rango, pero las ordena en mayúscula primero en una partición.

    Puede obtener un resultado similar con Babelfish mediante la adición de una cláusula COLLATE a la cláusula ORDER BY que especifica una intercalación terciaria CS_AS que especifica @colCaseFirst=upper. Sin embargo, el modificador colCaseFirst se aplica solo a cadenas terciarias iguales (en lugar de secundarias iguales, como sucede con una intercalación CI_AS). Por lo tanto, no se pueden emular las intercalaciones de SQL terciarias mediante una única intercalación de ICU.

    Como solución alternativa, le recomendamos que modifique las aplicaciones que utilizan la intercalación SQL_Latin1_General_Pref_CP1_CI_AS para utilizar la intercalación BBF_SQL_Latin1_General_CP1_CI_AS en primer lugar. A continuación, agregue COLLATE BBF_SQL_Latin1_General_Pref_CP1_CS_AS a cualquier cláusula ORDER BY de esta columna.

  • Expansión de caracteres: una expansión de caracteres trata a un solo carácter igual que a una secuencia de caracteres del nivel principal. La intercalación CI_AS predeterminada de SQL Server admite la expansión de caracteres. Las intercalaciones de UCI admiten la expansión de caracteres solo en las intercalaciones que no distinguen los acentos.

    Cuando sea necesaria la expansión de caracteres, utilice una intercalación AI para obtener comparaciones. Sin embargo, el operador LIKE no admite actualmente estas intercalaciones.

  • Codificación char y varchar: cuando se utilizan intercalaciones SQL para los tipos de datos char o varchar, el orden de clasificación de los caracteres anteriores a ASCII 127 viene determinado por la página de códigos específica para esa intercalación de SQL. Para las intercalaciones SQL, las cadenas declaradas como char o varchar pueden ordenarse de forma diferente a las cadenas declaradas como nchar o nvarchar.

    PostgreSQL codifica todas las cadenas con la codificación de la base de datos, de modo que se convierten todos los caracteres a UTF-8 y se ordenan mediante reglas Unicode.

    Dado que las intercalaciones de SQL ordenan los tipos de datos nchar y nvarchar mediante reglas Unicode, Babelfish codifica todas las cadenas del servidor mediante UTF-8. Babelfish ordena las cadenas nchar y nvarchar de la misma manera que ordena las cadenas char y varchar mediante las reglas Unicode.

  • Carácter suplementario: las funciones NCHAR, UNICODE y LEN de SQL Server admiten caracteres para puntos de código fuera del Plano Básico Multilingüe (BMP) de Unicode. Por el contrario, las intercalaciones que no son SC utilizan caracteres pares sustitutos para gestionar caracteres complementarios. Para los tipos de datos Unicode, SQL Server puede representar hasta 65 535 caracteres mediante UCS-2 o el rango Unicode completo (1,114,114 caracteres) si se utilizan caracteres complementarios.

  • Intercalaciones con distinción de los tipos de kana (KS): una intercalación con distinción de los tipos de kana (KS) trata los caracteres kana japoneses Hiragana y Katakana de forma diferente. ICU admite el estándar de intercalación japonés JIS X 4061. El ahora obsoleto modificador colhiraganaQ [on | off] de configuración regional podría proporcionar la misma funcionalidad que las intercalaciones de KS. Sin embargo, Babelfish no admite actualmente las intercalaciones de KS del mismo nombre que SQL Server.

  • Intercalaciones de distinción de ancho (WS): cuando un carácter de un byte (ancho medio) y el mismo carácter representado como un carácter de doble byte (ancho completo) se tratan de forma diferente, la intercalación se denomina de distinción de ancho (WS). Sin embargo, Babelfish no admite actualmente las intercalaciones de WS del mismo nombre que SQL Server.

  • Intercalaciones de distinción de selector de variaciones (VSS): las intercalaciones de distinción de selector de variaciones (VSS) distinguen entre los selectores de variaciones ideográficas en las intercalaciones en japonés Japanese_Bushu_Kakusu_140 y Japanese_XJIS_140. Una secuencia de variaciones se compone de un carácter base más un selector de variaciones adicional. Si no selecciona la opción _VSS, el selector de variaciones no se tiene en cuenta en la comparación.

    Babelfish no admite las intercalaciones de VSS.

  • Intercalaciones BIN y BIN2: una intercalación BIN2 ordena los caracteres según el orden de los puntos de código. El orden binario byte a byte de UTF-8 conserva el orden de puntos de código Unicode, por lo que también es probable que esta sea la intercalación de mejor rendimiento. Si el orden de puntos de código Unicode funciona para una aplicación, considere utilizar una intercalación BIN2. Sin embargo, el uso de una intercalación BIN2 puede provocar que los datos se muestren en el cliente en un orden inesperado culturalmente. Las nuevas asignaciones a caracteres en minúscula se agregan a Unicode a medida que avanza el tiempo, por lo que la función LOWER puede funcionar de manera diferente en distintas versiones de ICU. Este es un caso especial del problema de control de versiones de intercalación más general, en lugar de como algo específico de la intercalación BIN2.

    Babelfish proporciona la intercalación de BBF_Latin1_General_BIN2 con la distribución de Babelfish para intercalar en el orden de puntos de código Unicode. En una intercalación BIN, solo el primer carácter se ordena como wchar. Los caracteres restantes se ordenan byte a byte, efectivamente en orden de puntos de código según su codificación. Este enfoque no sigue las reglas de intercalación Unicode y Babelfish no lo admite.

  • Intercalaciones no deterministas y limitación de CHARINDEX: en las versiones de Babelfish anteriores a la 2.1.0, no puede utilizar CHARINDEX con intercalaciones no deterministas. De forma predeterminada, Babelfish utiliza una intercalación sin distinción de mayúsculas y minúsculas (no determinista). El uso de CHARINDEX para las versiones más antiguas de Babelfish genera el siguiente error de ejecución:

    nondeterministic collations are not supported for substring searches
    nota

    Esta limitación y esta solución alternativa se aplican solo a la versión 1.x de Babelfish (versiones Aurora PostgreSQL 13.x). Las versiones 2.1.0 y posteriores de Babelfish no tienen este problema.

    Puede solucionar este problema de una de las siguientes maneras:

    • Convierta explícitamente la expresión en una intercalación distinta entre mayúsculas y minúsculas y doble ambos argumentos aplicando LOWER o UPPER. Por ejemplo, SELECT charindex('x', a) FROM t1 se convertiría en lo siguiente:

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

    • Cree una función SQL f_charindex y reemplace las llamadas de CHARINDEX por llamadas a la siguiente función:

      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