configurações de sessão de analyzer_compatibility_*

Essas configurações estão disponíveis em system.settings e são geradas automaticamente a partir do código-fonte.

Permite adicionar identificadores compostos ao nested. Esta é uma configuração de compatibilidade porque altera o resultado da consulta. Quando desabilitada, SELECT a.b.c FROM table ARRAY JOIN a não funciona, e SELECT a FROM table não inclui a coluna a.b.c no resultado de Nested a.

Quando habilitada, o analyzer reproduz o comportamento legado de mover conjunções com AND não agregadas de HAVING para WHERE, em vez de gerar NOT_AN_AGGREGATE. A rejeição em conformidade com o padrão é o comportamento padrão; esta configuração serve como auxílio de migração para consultas que eram aceitas silenciosamente pelo analyzer antigo (enable_analyzer = 0). Conjunções que contêm funções de agregação, grouping ou funções não determinísticas permanecem em HAVING. Se qualquer conjunção contiver uma função de janela ou uma função com estado (por exemplo, rowNumberInBlock), a reescrita será desabilitada para todo o HAVING, em linha com o comportamento legado do PredicateExpressionsOptimizer. A configuração também é ignorada quando GROUP BY usa WITH CUBE, WITH ROLLUP, WITH TOTALS ou GROUPING SETS.

Restaura o comportamento das versões anteriores à 26.6, em que o modificador FINAL especificado na tabela mais à esquerda de um JOIN era incorretamente aplicado também a todas as demais tabelas unidas (para motores compatíveis com FINAL, como ReplacingMergeTree). Por padrão, FINAL se aplica apenas à tabela em que foi especificado. Habilite esta opção para compatibilidade com consultas que dependem do comportamento antigo; a correção recomendada é especificar FINAL explicitamente em cada tabela que precisar dele.

Valores possíveis:

• 0 - FINAL se aplica apenas à tabela em que foi especificado.
• 1 - FINAL na tabela mais à esquerda de um JOIN é aplicado a todas as tabelas unidas.

Força a resolução do identificador em JOIN USING a partir da projeção (por exemplo, em SELECT a + 1 AS b FROM t1 JOIN t2 USING (b), o join será realizado por t1.a + 1 = t2.b, em vez de t1.b = t2.b). Aliases definidos em subexpressões na lista SELECT também são considerados (por exemplo, em SELECT uniqExact(a + 1 AS b) FROM t1 JOIN t2 USING (b), o join é realizado por t1.a + 1 = t2.b). Quando o alias correspondente é definido em uma subexpressão na lista SELECT, em vez de como um alias de nível superior, as réplicas paralelas são desativadas para a consulta. Para consultas enviadas a servidores remotos (tabelas Distributed, a função de tabela remote), essa consulta é rejeitada com uma exceção somente quando o identificador não pode ser resolvido no servidor remoto; se o alias mascarar uma coluna real da tabela à esquerda, o servidor remoto realizará o join por essa coluna, portanto os resultados poderão diferir da execução local.

Quando ativada e a cláusula FROM de uma consulta contém dois ou mais JOINs (tabelas separadas por vírgulas contam; ARRAY JOIN não), o analyzer nomeia as colunas de resultado da mesma forma que a reescrita de múltiplas junções do analyzer antigo:

• as colunas produzidas pela expansão de *, <table>.* ou COLUMNS('<regexp>') recebem nomes no formato <alias-or-table>.<column> (o qualificador é o alias da expressão de tabela, se houver; caso contrário, o nome da tabela sem o banco de dados; ou, se aplicável, o nome da CTE; colunas de uma subconsulta incluída em uma junção sem alias permanecem não qualificadas). Dois tipos de coluna mantêm seu nome simples porque pertencem à junção, e não a uma única expressão de tabela: uma coluna produzida por ARRAY JOIN e uma chave mesclada por JOIN ... USING. Portanto, referências externas como SELECT ll.arr ou SELECT ll.k não são resolvidas nessas duas formas;
• a forma de lista de identificadores COLUMNS(col1, col2) não é uma expansão de correspondência: cada coluna mantém o nome exatamente como seu identificador foi escrito; assim, COLUMNS(x) produz x e COLUMNS(a.x) produz a.x;
• uma referência de coluna sem alias na lista SELECT mantém o nome exatamente como foi escrita (por exemplo, SELECT a.x produz uma coluna chamada a.x mesmo quando x não é ambígua).

Isso permite que consultas externas que referenciam essas colunas pelos nomes qualificados funcionem, por exemplo:

SELECT ll.Date FROM (SELECT * FROM t AS ll LEFT JOIN t1 ON ll.k = t1.k LEFT JOIN t2 ON ll.k = t2.k);

Tem efeito apenas quando o analyzer está habilitado (enable_analyzer = 1).

Quando um identificador composto como b.id pode se referir tanto à coluna id de uma tabela com alias b quanto à subcoluna Tuple b.id de alguma outra coluna, prefira a interpretação com prefixo de alias (coluna id de b). Por padrão, o analyzer prefere a subcoluna. Ative esta opção para corresponder à resolução do analyzer antigo.