A consulta de igualdade na coluna NVARCHAR gera vários resultados no SQL Server 2012

Estou no processo de mover um projeto para animais de estimação do PostgreSQL (9.2.2) para o SQL Server (2012 Standard).

Percebi um fenômeno interessante ao consultar palavras unicode. Dada a definição:

CREATE TABLE [word](
    [id] [int] IDENTITY(0,1) NOT NULL,
    [value] [nvarchar](255) NULL    
 );

e os dados:

insert into word (value) values (N'ῥύπῳ');
insert into word  (value) values (N'ἀπὸ');
insert into word  (value) values (N'ἀπό');
insert into word (value) values  (N'ἐπὶ');
insert into word (value) values  (N'ἐπί');
insert into word (value) values  (N'ὑπὸ');
insert into word (value) values  (N'ὑπό');
insert into word (value) values  (N'πίῃ');

insert into word  (value) values (N'λόγους');
insert into word  (value) values (N'λόγχῃ');
insert into word (value) values  (N'λόγων');
insert into word  (value) values (N'ἀλόης');

uma consulta para uma palavra específica retornará correspondências próximas. Por exemplo:

select * from word where value = N'ἀπὸ'

retorna:

id  value
102137  ῥύπῳ
102141  ἀπὸ
102142  ἀπό
102143  ἐπὶ
102144  ἐπί
102145  ὑπὸ
102146  ὑπό
102147  πίῃ

http://sqlfiddle.com/#!6/1ab66/1

No entanto, o mesmo padrão no PostgreSQL retorna apenas a correspondência exata. Como posso obter o SQL Server para fazer o mesmo?

(Link de violino do PostgreSQL): http://sqlfiddle.com/#!12/c57a6/1

Tenho a sensação distinta de que estou perdendo alguma coisa, mas não sou capaz de descobrir o que é.

O agrupamento do banco de dados é SQL_Latin1_General_CP1_CI_AS(que também é o agrupamento do servidor) em uma instalação local.

sql-server postgresql

— swasheck
fonte

O agrupamento determina a semântica da comparação.

Se eu tentar

CREATE TABLE [word](
    [id] [int] IDENTITY(0,1) NOT NULL,
    [value] [nvarchar](255) COLLATE Latin1_General_100_CI_AS NULL    
 );

Apenas retorna ἀπὸ.

Alterar o sufixo para AIretornos insensíveis ao acento ἀπόtambém.

Na minha instalação, tentei todos os agrupamentos e 1526retornos 1(presumivelmente ASe BINagrupamentos), 1264retornei 2 linhas (presumivelmente AI) e 1095retornei 8.

De uma rápida olhada neste último grupo, parece incluir todos os SQLagrupamentos e 90agrupamentos, enquanto todos 100estão nos dois primeiros grupos, portanto, presumo que esse seja um problema que foi corrigido no lote de agrupamentos de 2008. (Consulte O que há de novo nos agrupamentos do SQL Server 2008 )

Script para tentar você mesmo

DECLARE @Results TABLE
(
Count INT,
Collation SYSNAME
)

SET NOCOUNT ON;
DECLARE @N SYSNAME;
DECLARE @C1 AS CURSOR;
SET @C1 = CURSOR FAST_FORWARD FOR 
SELECT name
FROM sys.fn_helpcollations();
OPEN @C1;
FETCH NEXT FROM @C1 INTO @N ;
WHILE @@FETCH_STATUS = 0
BEGIN
  INSERT @Results
  EXEC('SELECT COUNT(*), ''' + @N + ''' from word where value = N''ἀπὸ'' COLLATE ' + @N)
  FETCH NEXT FROM @C1 INTO @N ;
END

SELECT *
FROM @Results
ORDER BY Count DESC

— Martin Smith
fonte