Skip to main content
Ces paramètres sont disponibles dans system.settings et sont générés automatiquement à partir du source.

​
analyzer_compatibility_allow_compound_identifiers_in_unflatten_nested

Permet d’ajouter des identifiants composés à Nested. Il s’agit d’un paramètre de compatibilité, car il modifie le résultat de la requête. Lorsqu’il est désactivé, SELECT a.b.c FROM table ARRAY JOIN a ne fonctionne pas, et SELECT a FROM table n’inclut pas la colonne a.b.c dans le résultat Nested a.

​
analyzer_compatibility_allow_cte_redefinition

Permet de définir plusieurs fois le nom d’une Common Table Expression dans une même clause WITH. Une référence à un tel nom est liée à la dernière définition qui n’est pas en cours de résolution à ce moment-là : une redéfinition peut lire la définition précédente du même nom, tandis que le corps de la requête lit la dernière. Ce comportement correspond à l’analyse de requêtes utilisée par ClickHouse avant la v24.3, dans laquelle une définition ultérieure masquait silencieusement les précédentes. Un cas de figure diffère toutefois de cette ancienne analyse : une CTE déclarée entre deux définitions d’un même nom est elle aussi liée à la dernière définition, alors que l’ancienne analyse la liait à la définition visible à l’endroit de sa déclaration. Par défaut, une redéfinition est rejetée avec l’erreur MULTIPLE_EXPRESSIONS_FOR_ALIAS. Une CTE déclarée comme MATERIALIZED et une CTE figurant dans une clause WITH RECURSIVE ne peuvent pas être redéfinies, même lorsque le paramètre est activé. Valeurs possibles :
  • 0 - Un nom de CTE ne peut être défini qu’une seule fois dans une clause WITH.
  • 1 - Une définition ultérieure d’un nom de CTE masque les précédentes.

​
analyzer_compatibility_allow_non_aggregate_in_having

Lorsqu’il est activé, l’analyseur reproduit le comportement legacy qui consiste à déplacer les AND-conjuncts non agrégés de HAVING vers WHERE au lieu de lever NOT_AN_AGGREGATE. Le rejet conforme à la norme est le comportement par défaut ; il s’agit d’une aide à la migration pour les requêtes qui étaient acceptées silencieusement par l’analyse de requêtes utilisée par ClickHouse avant la v24.3. Les conjuncts contenant des fonctions d’agrégation, grouping ou des fonctions non déterministes restent dans HAVING. Si un conjunct contient une window function ou une fonction avec état (par exemple rowNumberInBlock), la réécriture est désactivée pour l’ensemble de HAVING, conformément au comportement de cette ancienne analyse. Le paramètre est également ignoré lorsque GROUP BY utilise WITH CUBE, WITH ROLLUP, WITH TOTALS ou GROUPING SETS.

​
analyzer_compatibility_apply_final_to_all_joined_tables

Restaure le comportement des versions antérieures à 26.6, dans lesquelles le modificateur FINAL spécifié sur la table la plus à gauche d’un JOIN était également appliqué de manière incorrecte à toutes les autres tables jointes (pour les moteurs prenant en charge FINAL, par exemple ReplacingMergeTree). Par défaut, FINAL s’applique uniquement à la table sur laquelle il est indiqué. Activez ce paramètre pour assurer la compatibilité avec les requêtes reposant sur l’ancien comportement ; la correction recommandée consiste à indiquer explicitement FINAL sur chaque table qui en a besoin. Valeurs possibles :
  • 0 - FINAL s’applique uniquement à la table sur laquelle il est indiqué.
  • 1 - FINAL sur la table la plus à gauche d’un JOIN est appliqué à toutes les tables jointes.

​
analyzer_compatibility_join_using_top_level_identifier

Forcer la résolution de l’identifiant dans JOIN USING depuis la projection (par exemple, dans SELECT a + 1 AS b FROM t1 JOIN t2 USING (b), la jointure sera effectuée sur t1.a + 1 = t2.b, plutôt que sur t1.b = t2.b). Les alias définis ailleurs dans la requête sont également pris en compte : dans la clause WITH, sur des sous-expressions de la liste SELECT ou dans d’autres clauses (par exemple, dans WITH a + 1 AS b SELECT count() FROM t1 JOIN t2 USING (b) et dans SELECT uniqExact(a + 1 AS b) FROM t1 JOIN t2 USING (b), la jointure est effectuée sur t1.a + 1 = t2.b). Dans une requête comportant plusieurs JOIN, seul le JOIN le plus externe résout son identifiant USING à partir d’un alias ; un JOIN interne le résout à partir de sa table de gauche, comme le faisait l’ancien analyseur. Lorsque l’alias correspondant n’est pas un alias de niveau supérieur de la liste SELECT, les répliques parallèles sont désactivées pour la requête. Pour les requêtes envoyées à des serveurs distants (tables Distributed, fonction de table remote), une telle requête n’est rejetée avec une exception que si l’identifiant ne peut absolument pas être résolu sur le serveur distant ; si l’alias masque une véritable colonne de la table de gauche, le serveur distant effectue alors la jointure sur cette colonne, de sorte que les résultats peuvent différer de l’exécution locale.

​
analyzer_compatibility_multiple_joins_qualify_column_names

Lorsqu’il est activé et que la clause FROM d’une requête contient au moins deux JOIN (les tables séparées par des virgules sont comptées, contrairement à ARRAY JOIN), l’analyseur attribue aux colonnes de résultat les noms que leur donnait la réécriture des jointures multiples de l’ancien analyseur :
  • les colonnes produites par le développement de *, <table>.* ou COLUMNS('<regexp>') reçoivent des noms de la forme <alias-or-table>.<column> (le qualificateur est l’alias de l’expression de table si elle en possède un, sinon le nom de la table sans la base de données, ou, à défaut, le nom de la CTE ; les colonnes d’une sous-requête jointe sans alias restent non qualifiées). Deux types de colonnes conservent leur nom simple, car elles appartiennent à la jointure plutôt qu’à une seule expression de table : une colonne produite par ARRAY JOIN et une clé fusionnée par JOIN ... USING. Les références externes telles que SELECT ll.arr ou SELECT ll.k ne sont donc pas résolues dans ces deux cas ;
  • la forme sous forme de liste d’identifiants COLUMNS(col1, col2) ne correspond pas à un développement par correspondance : chaque colonne conserve exactement le nom sous lequel son identifiant a été écrit. Ainsi, COLUMNS(x) produit x et COLUMNS(a.x) produit a.x ;
  • une référence de colonne sans alias dans la liste SELECT conserve exactement le nom sous lequel elle a été écrite (par ex., SELECT a.x produit une colonne nommée a.x même lorsque x est non ambigu).
Cela permet aux requêtes externes qui référencent ces colonnes par leur nom qualifié de fonctionner, par exemple :

​
analyzer_compatibility_prefer_alias_over_subcolumn

Lorsqu’un identifiant composite comme b.id peut faire référence soit à la colonne id d’une table ayant pour alias b, soit à une sous-colonne Tuple b.id d’une autre colonne, privilégiez l’interprétation avec préfixe d’alias (colonne id de b). Par défaut, l’analyseur privilégie la sous-colonne. Activez ce paramètre pour retrouver la résolution de l’ancien analyseur.