Skip to main content
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_cte_redefinition

Permite que o nome de uma Common Table Expression seja definido mais de uma vez em uma única cláusula WITH. Uma referência a esse nome é vinculada à definição mais recente que não esteja sendo resolvida naquele momento: uma redefinição pode ler a definição anterior do mesmo nome, e o corpo da consulta lê a última. Esse é o comportamento da análise de consultas que o ClickHouse usava antes da v24.3, na qual uma definição posterior sobrepunha silenciosamente as anteriores. Há um caso em que o comportamento difere daquela análise: uma CTE declarada entre duas definições de um nome também é vinculada à última definição, enquanto a análise antiga a vinculava à definição visível no ponto em que foi declarada. Por padrão, uma redefinição é rejeitada com o erro MULTIPLE_EXPRESSIONS_FOR_ALIAS. Uma CTE declarada como MATERIALIZED e uma CTE em uma cláusula WITH RECURSIVE não podem ser redefinidas, mesmo com a configuração habilitada. Valores possíveis:
  • 0 - Um nome de CTE só pode ser definido uma vez em uma cláusula WITH.
  • 1 - Uma definição posterior de um nome de CTE sobrepõe as anteriores.

analyzer_compatibility_allow_non_aggregate_in_having

Quando habilitada, o analisador 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 daquela análise mais antiga. 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), a junção será realizada por t1.a + 1 = t2.b, em vez de t1.b = t2.b). Aliases definidos em outras partes da consulta também são considerados: na cláusula WITH, em subexpressões na lista SELECT ou em outras cláusulas (por exemplo, em WITH a + 1 AS b SELECT count() FROM t1 JOIN t2 USING (b) e em SELECT uniqExact(a + 1 AS b) FROM t1 JOIN t2 USING (b), a junção é realizada por t1.a + 1 = t2.b). Em uma consulta com vários JOINs, somente o JOIN mais externo resolve seu identificador USING a partir de um alias; um JOIN interno o resolve a partir de sua tabela à esquerda, como fazia o analisador antigo. Quando o alias correspondente não é um alias de nível superior da lista SELECT, 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á a junção 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:

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.