analyzer_compatibility_* session settings

ClickHouse session settings in the analyzer_compatibility_* generated group.

These settings are available in system.settings and are autogenerated from source.

analyzer_compatibility_allow_compound_identifiers_in_unflatten_nested

Allow to add compound identifiers to nested. This is a compatibility setting because it changes the query result. When disabled, SELECT a.b.c FROM table ARRAY JOIN a does not work, and SELECT a FROM table does not include a.b.c column into Nested a result.

analyzer_compatibility_allow_cte_redefinition

Allow a Common Table Expression name to be defined more than once in a single WITH clause. A reference to such a name binds to the latest definition that is not being resolved at that moment: a redefinition can read the previous definition of the same name, and the query body reads the last one. This matches the query analysis that ClickHouse used before v24.3, where a later definition silently shadowed the earlier ones. One shape differs from that analysis: a CTE declared between two definitions of a name also binds to the last definition, where the old analysis bound it to the definition visible at its declaration point. By default a redefinition is rejected with MULTIPLE_EXPRESSIONS_FOR_ALIAS. A CTE declared as MATERIALIZED and a CTE in a WITH RECURSIVE clause cannot be redefined even when the setting is enabled.

Possible values:

• 0 - A CTE name can be defined only once in a WITH clause.
• 1 - A later definition of a CTE name shadows the earlier ones.

analyzer_compatibility_allow_non_aggregate_in_having

When enabled, the analyzer mimics the legacy behavior of moving non-aggregate AND-conjuncts from HAVING to WHERE instead of raising NOT_AN_AGGREGATE. The standard-compliant rejection is the default; this is a migration aid for queries that were silently accepted by the query analysis that ClickHouse used before v24.3. Conjuncts containing aggregate, grouping, or non-deterministic functions stay in HAVING. If any conjunct contains a window function or a stateful function (for example rowNumberInBlock), the rewrite is disabled for the whole HAVING, matching the behaviour of that older analysis. The setting is also ignored when GROUP BY uses WITH CUBE, WITH ROLLUP, WITH TOTALS, or GROUPING SETS.

analyzer_compatibility_apply_final_to_all_joined_tables

Restores the behavior of versions before 26.6, where the FINAL modifier specified on the left-most table of a JOIN was incorrectly applied to all other joined tables as well (for engines that support FINAL, e.g. ReplacingMergeTree). By default FINAL applies only to the table it is written on. Enable for compatibility with queries that rely on the old behavior; the recommended fix is to write FINAL explicitly on every table that needs it.

Possible values:

• 0 - FINAL applies only to the table it is specified on.
• 1 - FINAL on the left-most table of a JOIN is applied to all joined tables.

analyzer_compatibility_join_using_top_level_identifier

Force to resolve identifier in JOIN USING from projection (for example, in SELECT a + 1 AS b FROM t1 JOIN t2 USING (b) join will be performed by t1.a + 1 = t2.b, rather then t1.b = t2.b). Aliases defined elsewhere in the query are also considered: in the WITH clause, on subexpressions inside the SELECT list, or in other clauses (for example, in WITH a + 1 AS b SELECT count() FROM t1 JOIN t2 USING (b) and in SELECT uniqExact(a + 1 AS b) FROM t1 JOIN t2 USING (b) the join is performed by t1.a + 1 = t2.b). In a query with several JOINs only the outermost JOIN resolves its USING identifier from an alias; an inner JOIN resolves it from its left table, as the old analyzer did. When the matching alias is not a top-level alias of the SELECT list, parallel replicas are disabled for the query. For queries sent to remote servers (Distributed tables, the remote table function), such a query is rejected with an exception only when the identifier cannot be resolved on the remote server at all; if the alias shadows a real column of the left table, the remote server joins by that column instead, so the results may differ from local execution.

analyzer_compatibility_multiple_joins_qualify_column_names

When enabled and the FROM clause of a query contains two or more JOINs (comma-separated tables count; ARRAY JOIN does not), the analyzer names result columns the way the old analyzer’s multiple-joins rewrite did:

• columns produced by expanding *, <table>.* or COLUMNS('<regexp>') get names of the form <alias-or-table>.<column> (the qualifier is the table expression’s alias if it has one, otherwise the table name without the database, otherwise the CTE name; columns of a joined subquery without an alias are left unqualified). Two kinds of column keep their bare name because they belong to the join rather than to a single table expression: a column produced by ARRAY JOIN, and a key merged by JOIN ... USING. Outer references such as SELECT ll.arr or SELECT ll.k therefore do not resolve in those two shapes;
• the identifier-list form COLUMNS(col1, col2) is not a matcher expansion: each column keeps the name exactly as its identifier was written, so COLUMNS(x) produces x and COLUMNS(a.x) produces a.x;
• an unaliased column reference in the SELECT list keeps its name exactly as written (e.g. SELECT a.x produces a column named a.x even when x is unambiguous).

This makes outer queries that reference such columns by their qualified names work, for example:

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

When a multi-part identifier like b.id could refer to either the column id of a table aliased b or to a Tuple subcolumn b.id of some other column, prefer the alias-prefix interpretation (column id of b). By default the analyzer prefers the subcolumn. Enable to match the old analyzer’s resolution.