paramètres de session analyzer_compatibility_*

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

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.

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'ancien analyseur (enable_analyzer = 0). 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 legacy de PredicateExpressionsOptimizer. Le paramètre est également ignoré lorsque GROUP BY utilise WITH CUBE, WITH ROLLUP, WITH TOTALS ou GROUPING SETS.

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.

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 sur des sous-expressions dans la liste SELECT sont également pris en compte (par exemple, dans SELECT uniqExact(a + 1 AS b) FROM t1 JOIN t2 USING (b), la jointure est effectuée sur t1.a + 1 = t2.b). Lorsque l’alias correspondant est défini sur une sous-expression dans la liste SELECT plutôt que comme alias de niveau supérieur, 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.

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 :

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

Ne prend effet que si l’analyseur est activé (enable_analyzer = 1).

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.