Limites et différences de comportement des classements

Babelfish utilise la bibliothèque ICU pour la prise en charge des classements. PostgreSQL repose sur une version spécifique d'ICU et ne peut correspondre qu'à une seule version d'un classement. Les variations d'une version à l'autre sont inévitables, de même que les variations mineures dans le temps à mesure que les langues évoluent. La liste suivante répertorie les limites et variations de comportement connues pour les classements Babelfish :

• Index et dépendance de type de classement : un index figurant sur un type défini par l'utilisateur qui dépend de la bibliothèque de classements International Components for Unicode (ICU – la bibliothèque utilisée par Babelfish) n'est pas invalidé lorsque la version de la bibliothèque est modifiée.

• Fonction COLLATIONPROPERTY : les propriétés de classement ne sont implémentées que pour les classements Babelfish BBF pris en charge. Pour plus d'informations, consultez le Babelfish supported collations table.

• Différences entre les règles de tri Unicode : les classements SQL pour SQL Server trient les données codées en Unicode (nchar et nvarchar) différemment des données qui ne sont pas codées en Unicode (char et varchar). Les bases de données Babelfish sont toujours codées en UTF-8 et appliquent toujours les règles de tri Unicode de manière cohérente, quel que soit le type de données. L'ordre de tri de char ou varchar est donc identique à celui de nchar ou nvarchar.

• Classements à égalité secondaire et comportement de tri : le classement ICU Unicode secondaire par défaut (CI_AS) trie les signes de ponctuation et les autres caractères non alphanumériques avant les caractères numériques, et les caractères numériques avant les caractères alphabétiques. Toutefois, l'ordre des signes de ponctuation et des autres caractères spéciaux est différent.

• Classements tertiaires, solution de contournement pour ORDER BY : les classements SQL, tels que SQL_Latin1_General_Pref_CP1_CI_AS, prennent en charge la fonction TERTIARY_WEIGHTS et la capacité à trier les chaînes considérées comme égales au sein d'un classement CI_AS afin que le tri s'effectue d'abord sur les majuscules : ABC, ABc, AbC, Abc, aBC, aBc, abC et enfin abc. Ainsi, la fonction analytique DENSE_RANK OVER (ORDER BY column) évalue ces chaînes comme ayant le même rang, mais les classe en commençant par les majuscules au sein d'une partition.

  Vous pouvez obtenir un résultat similaire avec Babelfish en ajoutant une clause COLLATE à la clause ORDER BY qui spécifie un classement CS_AS tertiaire indiquant @colCaseFirst=upper. Toutefois, le modificateur colCaseFirst s'applique uniquement aux chaînes qui présentent une égalité tertiaire (plutôt qu'une égalité secondaire comme avec le classement CI_AS). Par conséquent, vous ne pouvez pas émuler des classements SQL tertiaires à l'aide d'un seul classement ICU.

  Pour contourner ce problème, nous vous recommandons de modifier les applications qui utilisent le classement SQL_Latin1_General_Pref_CP1_CI_AS afin d'utiliser le classement BBF_SQL_Latin1_General_CP1_CI_AS en premier. Ajoutez ensuite COLLATE BBF_SQL_Latin1_General_Pref_CP1_CS_AS à n'importe quelle clause ORDER BY de cette colonne.

• Extension de caractère : une extension de caractère traite un caractère comme étant égal à une séquence de caractères au niveau primaire. Le classement CI_AS par défaut de SQL Server prend en charge l'extension de caractère. Les classements ICU prennent en charge l'extension de caractère uniquement pour les classements insensibles aux accents.

  Lorsqu'une extension de caractère est nécessaire, utilisez un classement AI pour les comparaisons. Toutefois, ces classements ne sont actuellement pas pris en charge par l'opérateur LIKE.

• Codage char et varchar : lorsque des classements SQL sont utilisés pour les types de données char ou varchar, l'ordre de tri des caractères précédant le code ASCII 127 est déterminé par la page de code spécifique de ce classement SQL. Pour les classements SQL, les chaînes déclarées comme char ou varchar peuvent être triées différemment des chaînes déclarées comme nchar ou nvarchar.

  PostgreSQL code toutes les chaînes avec le codage de la base de données afin de convertir tous les caractères en UTF-8 et de les trier à l'aide des règles Unicode.

  Étant donné que les classements SQL trient les types de données nchar et nvarchar à l'aide de règles Unicode, Babelfish encode toutes les chaînes du serveur en utilisant UTF-8. Babelfish trie les chaînes nchar et nvarchar de la même manière que les chaînes char et varchar, en utilisant les règles Unicode.

• Caractère supplémentaire : les fonctions SQL Server NCHAR, UNICODE et LEN prennent en charge les caractères des points de code en dehors du plan multilingue de base (BMP) Unicode. En revanche, les classements non SC utilisent des caractères de paire de substitution pour gérer les caractères supplémentaires. Pour les types de données Unicode, SQL Server peut représenter jusqu'à 65 535 caractères en utilisant la norme UCS-2, ou toute la gamme Unicode (1 114 111 caractères) si des caractères supplémentaires sont utilisés.

• Classements sensibles aux kanas (KS) : un classement sensible aux kanas (KS) traite les caractères japonais (kanas) Hiragana et Katakana différemment. ICU prend en charge la norme de classement japonaise JIS X 4061. Le modificateur de paramètres locaux colhiraganaQ [on | off], désormais obsolète, peut fournir la même fonctionnalité que les classements KS. Toutefois, les classements KS du même nom que ceux de SQL Server ne sont actuellement pas pris en charge par Babelfish.

• Classements sensibles à la largeur (WS) : lorsqu'un caractère d'un seul octet (demi-largeur) et le même caractère représenté par un caractère de deux octets (pleine largeur) sont traités différemment, le classement est dit sensible à la largeur (WS). Les classements WS portant le même nom que ceux de SQL Server ne sont actuellement pas pris en charge par Babelfish.

• Classements VSS (sensibilité au sélecteur de variante) : les classements VSS (sensibilité au sélecteur de variante) font la distinction entre les sélecteurs de variantes idéographiques dans les classements japonais Japanese_Bushu_Kakusu_140 et Japanese_XJIS_140. Une séquence de variantes est constituée d'un caractère de base et d'un sélecteur de variante supplémentaire. Si vous ne sélectionnez pas le champ _VSS, le sélecteur de variante n'est pas pris en compte dans la comparaison.

  Les classements VSS ne sont actuellement pas pris en charge par Babelfish.

• Classements BIN et BIN2 : un classement BIN2 trie les caractères en fonction de l'ordre des points de code. L'ordre binaire octet par octet du format UTF-8 préserve l'ordre des points de code Unicode, ce qui en fait probablement le classement le plus performant. Si l'ordre des points de code Unicode fonctionne pour une application, n'hésitez pas à utiliser un classement BIN2. Toutefois, l'utilisation d'un classement BIN2 peut entraîner l'affichage des données dans un ordre culturellement inattendu sur le client. De nouveaux mappages vers des caractères minuscules sont ajoutés à Unicode au fil du temps. LOWER peut donc fonctionner différemment selon les versions d'ICU. Il s'agit d'un cas particulier du problème plus général de gestion des versions du classement plutôt que d'un problème spécifique au classement BIN2.

  Babelfish fournit le classement BBF_Latin1_General_BIN2 avec la distribution Babelfish pour assembler dans l'ordre les points de code Unicode. Dans un classement BIN, seul le premier caractère est trié en tant que wchar. Les autres caractères sont triés octet par octet, dans l'ordre des points de code en fonction de leur encodage. Cette approche ne suit pas les règles de classement Unicode et n'est pas prise en charge par Babelfish.

• Classements non déterministes et limite CHARINDEX : pour les versions de Babelfish antérieures à la version 2.1.0, vous ne pouvez pas utiliser CHARINDEX avec des classements non déterministes. Par défaut, Babelfish utilise un classement insensible à la casse (non déterministe). L'utilisation de CHARINDEX pour les versions antérieures de Babelfish génère l'erreur d'exécution suivante :

  nondeterministic collations are not supported for substring searches

  Note

  Cette limite et cette solution de contournement s'appliquent uniquement à Babelfish version 1.x (Aurora PostgreSQL versions 13.x). Babelfish 2.1.0 et versions ultérieures ne présentent pas ce problème.

  Vous pouvez contourner ce problème de l'une des manières suivantes :

  • Convertir explicitement l'expression en une collation sensible à la casse et respecter la casse des deux arguments en appliquant les instructions LOWER ou UPPER. Par exemple, la commande SELECT charindex('x', a) FROM t1 deviendrait ce qui suit :

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

  • Créez une fonction SQL f_charindex, et remplacez les appels à CHARINDEX par des appels à la fonction suivante :

    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