Limitazioni di regole di confronto e differenze di comportamento

Babelfish utilizza la libreria ICU per il supporto delle raccolte. PostgreSQL è costruito con una versione specifica di ICU e può corrispondere al massimo a una versione di un confronto. Le variazioni tra le versioni sono inevitabili, così come le piccole variazioni nel tempo man mano che le lingue evolvono. Nella sezione seguente sono disponibili le limitazioni note e le variazioni di comportamento delle regole di confronto Babelfish:

• Indici e dipendenza tipo regola di confronto: un indice su un tipo definito dall'utente che dipende dalla libreria di regole di confronto ICU (International Components for Unicode) (la libreria utilizzata da Babelfish) non viene invalidato quando la versione della libreria viene modificata.

• Funzione COLLATIONPROPERTY: le proprietà delle regole di confronto sono implementate solo per le regole di confronto Babelfish BBF supportate. Per ulteriori informazioni, consulta la Babelfish supported collations table.

• Differenze regole di ordinamento Unicode: le regole di confronto SQL per SQL Server ordinano i dati con codifica Unicode (nchar e nvarchar) in modo diverso rispetto ai dati senza codifica Unicode (char e varchar). I database Babelfish sono sempre codificati UTF-8 e applicano sempre regole di ordinamento Unicode in modo coerente, a prescindere dal tipo di dati, pertanto l'ordinamento per char o varchar è uguale a quello per nchar o nvarchar.

• Regole di confronto secondarie uguali e comportamento di ordinamento: la regola di confronto predefinita Unicode secondaria uguale (CI_AS) ordina i segni di punteggiatura e altri caratteri non alfanumerici prima dei caratteri numerici e i caratteri numerici prima dei caratteri alfabetici. Tuttavia, l'ordine di punteggiatura e altri caratteri speciali sono diversi.

• Regole di confronto terziarie, soluzione alternativa per ORDER BY: le regole di confronto SQL, ad esempio SQL_Latin1_General_Pref_CP1_CI_AS, supportano la funzione TERTIARY_WEIGHTS e la capacità di ordinare stringhe che si confrontano allo stesso modo in una regola di confronto CI_AS da ordinare prima in maiuscolo: ABC, ABc, AbC, Abc, aBC, aBc, abC e infine abc. Pertanto la funzione analitica DENSE_RANK OVER (ORDER BY column) valuta queste stringhe come aventi lo stesso rango, ma le ordina prima in maiuscolo all'interno di una partizione.

  Puoi ottenere un risultato simile con Babelfish aggiungendo una clausola COLLATEalla clausola ORDER BY che specifica una raccolta terziaria CS_AS che specifica @colCaseFirst=upper. Tuttavia, il modificatore colCaseFirst si applica esclusivamente alle stringhe terziarie uguali (piuttosto che secondarie-uguali come una regola di confronto CI_AS). Pertanto, non è possibile emulare raccolte SQL terziarie utilizzando una singola relazione ICU.

  Come soluzione alternativa, consigliamo di modificare le applicazioni che utilizzano la raccolta SQL_Latin1_General_Pref_CP1_CI_AS per utilizzare la raccolta BBF_SQL_Latin1_General_CP1_CI_AS prima di iniziare la raccolta. Quindi aggiungere COLLATE BBF_SQL_Latin1_General_Pref_CP1_CS_ASa qualsiasi clausola ORDER BY per questa colonna.

• Espansione di caratteri: un'espansione di caratteri tratta un singolo carattere come uguale a una sequenza di caratteri a livello primario. La regola di confronto CI_AS predefinita di SQL Server supporta l'espansione di caratteri. Le regole di confronto ICU supportano l'espansione di caratteri solo per regole di confronto senza distinzione caratteri accentati/non accentati.

  Quando è richiesta l'espansione dei caratteri, utilizzare una raccolta AI per confronti. Tuttavia, tali raccolte non sono attualmente supportate dall'operatore LIKE.

• Codifica char e varchar: quando le regole di confronto SQL vengono utilizzate per i tipi di dati char o varchar, l'ordinamento per i caratteri precedenti a ASCII 127 è determinato dalla pagina codice specifica per tale regola di confronto SQL. Per le regole di confronto SQL, le stringhe dichiarate come char o varchar potrebbero essere ordinate in modo diverso rispetto alle stringhe dichiarate come nchar o nvarchar.

  PostgreSQL codifica tutte le stringhe con la codifica del database, pertanto tutti i caratteri vengono convertiti in UTF-8 e ordinati utilizzando regole Unicode.

  Poiché le regole di confronto SQL ordinano i tipi di dati nchar e nvarchar utilizzando regole Unicode, Babelfish codifica tutte le stringhe sul server utilizzando UTF-8. Babelfish ordina le stringhe nchar e nvarchar nello stesso modo in cui ordina le stringhe char e varchar, usando regole Unicode.

• Caratteri supplementari: le funzioni SQL Server NCHAR, UNICODE, e LEN supportano i caratteri per i punti di codice al di fuori di Unicode Basic Multilingual Plane (BMP). Al contrario, le raccolte non SC utilizzano caratteri di coppia surrogata per gestire caratteri supplementari. Per i tipi di dati Unicode, SQL Server può rappresentare fino a 65.535 caratteri utilizzando UCS-2 o l'intervallo Unicode completo (1,114,114 caratteri) se si utilizzano caratteri supplementari.

• Regole di confronto con distinzione Kana (KS): una regola di confronto con distinzione Kana (KS) gestisce i caratteri Kana giapponesi Hiragana e Katakana in modo diverso. ICU supporta lo standard di raccolta giapponeseJIS X 4061. Il modificatore di localizzazione colhiraganaQ [on | off] oramai obsoleto potrebbe fornire la stessa funzionalità delle raccolte KS. Tuttavia, le raccolte KS con lo stesso nome di SQL Server non sono attualmente supportate da Babelfish.

• Regole di confronto con distinzione della larghezza (WS): quando un carattere a byte singolo (mezza larghezza) e lo stesso carattere rappresentato come carattere a doppio byte (larghezza intera) vengono trattati in modo diverso, la regola di confronto viene chiamata con distinzione della larghezza (WS). Le raccolte WS con lo stesso nome di SQL Server non sono attualmente supportate da Babelfish.

• Regole di confronto con distinzione selettore di variazione (VSS): le regole di confronto con distinzione selettore di variazione (VSS) distinguono tra selettori variazione ideografica nelle regole di confronto giapponesi Japanese_Bushu_Kakusu_140 e Japanese_XJIS_140. Una sequenza di varianti è costituita da un carattere base più un selettore di varianti aggiuntivo. Se non viene selezionata l'opzione _VSS, il selettore delle varianti non è considerato nel confronto.

  Le relazioni VSS attualmente non sono supportate da Babelfish.

• Regole di confronto BIN e BIN2: una regola di confronto BIN2 ordina i caratteri in base all'ordine dei punti di codice. L'ordine binario byte per byte di UTF-8 conserva l'ordine dei punti di codice Unicode, quindi è probabile che questo sia anche il confronto con le migliori raccolte. Se l'ordine dei punti di codice Unicode funziona per un'applicazione, prendere in considerazione l'utilizzo di una raccolta BIN2. Tuttavia, l'utilizzo di una raccolta BIN2 può comportare la visualizzazione dei dati sul client in un ordine culturalmente inaspettato. I nuovi mapping con caratteri minuscoli vengono aggiunti a Unicode man mano che il tempo progredisce, quindi la funzione LOWER potrebbe funzionare in modo diverso su diverse versioni di ICU. Questo è un caso speciale del problema di controllo delle versioni di raccolta più generale piuttosto che come qualcosa di specifico per la raccolta BIN2.

  Babelfish fornisce la raccolta BBF_Latin1_General_BIN2 con la distribuzione Babelfish da collare nell'ordine dei punti di codice Unicode. In una raccolta BIN solo il primo carattere viene ordinato come wchar. I caratteri rimanenti vengono ordinati byte per byte, in modo efficace in ordine di codice in base alla sua codifica. Questo approccio non segue le regole di confronto Unicode e non è supportato da Babelfish.

• Regole di confronto non deterministiche e limitazione CHARINDEX: per versioni di Babelfish precedenti alla versione 2.1.0, non è possibile utilizzare CHARINDEX con regole di confronto non deterministiche. Per impostazione predefinita, Babelfish utilizza una regola di confronto senza distinzione maiuscole/minuscole (non deterministica). L'utilizzo di CHARINDEX per le versioni precedenti di Babelfish genera il seguente errore di runtime:

  nondeterministic collations are not supported for substring searches

  Nota

  Questa limitazione e la soluzione alternativa si applicano solo a Babelfish versione 1.x (Aurora PostgreSQL versioni 13.x). Babelfish 2.1.0 e versioni successive non presentano questo problema.

  Puoi risolvere il problema in uno dei seguenti modi:

  • Converti esplicitamente l'espressione in un confronto con distinzione tra maiuscole e minuscole e trasforma entrambi gli argomenti applicando LOWER o UPPER. Ad esempio, SELECT charindex('x', a) FROM t1 diventa ciò che è indicato qui di seguito:

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

  • Crea una funzione SQL f_charindex e sostituisci le chiamate CHARINDEX con le chiamate alla seguente funzione:

    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