configurações de sessão de analyzer_compatibility_*

Configurações de sessão do ClickHouse no grupo gerado analyzer_compatibility_*.

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

​

analyzer_compatibility_allow_compound_identifiers_in_unflatten_nested

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.

​

analyzer_compatibility_allow_non_aggregate_in_having

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 pela análise de consultas que o ClickHouse usava antes da v24.3. 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.

​

analyzer_compatibility_apply_final_to_all_joined_tables

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.

​

analyzer_compatibility_join_using_top_level_identifier

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.

​

analyzer_compatibility_multiple_joins_qualify_column_names

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);

​

analyzer_compatibility_prefer_alias_over_subcolumn

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.