analyzer_compatibility_* セッション設定

analyzer_compatibility_* によって生成されたグループ内の ClickHouse セッション設定。

これらの設定は system.settings で確認でき、ソース から自動生成されています。

​

analyzer_compatibility_allow_compound_identifiers_in_unflatten_nested

Nested に複合 Identifier を追加できるようにします。これはクエリ結果が変わるため、互換性設定です。無効にすると、SELECT a.b.c FROM table ARRAY JOIN a は動作せず、SELECT a FROM table の結果にも a.b.c カラムは Nested a に含まれません。

​

analyzer_compatibility_allow_non_aggregate_in_having

有効にすると、アナライザは NOT_AN_AGGREGATE を返す代わりに、非集約の AND 条件を HAVING から WHERE に移動する従来の動作を再現します。デフォルトでは標準準拠の拒否動作が使われます。これは、古いアナライザ (enable_analyzer = 0) で暗黙的に受け入れられていたクエリのための移行支援です。集約関数、grouping、または非決定論的関数を含む条件は HAVING に残ります。いずれかの条件にウィンドウ関数または stateful function (たとえば rowNumberInBlock) が含まれている場合、書き換えは HAVING 全体で無効になり、従来の PredicateExpressionsOptimizer の動作と一致します。また、GROUP BY で WITH CUBE、WITH ROLLUP、WITH TOTALS、または GROUPING SETS を使用している場合、この設定は無視されます。

​

analyzer_compatibility_apply_final_to_all_joined_tables

JOIN の左端のテーブルに指定された FINAL 修飾子が、他のすべての結合先テーブルにも誤って適用されていた 26.6 より前のバージョンの動作を復元します (ReplacingMergeTree など、FINAL をサポートするエンジンの場合) 。デフォルトでは、FINAL は指定したテーブルにのみ適用されます。古い動作に依存するクエリとの互換性が必要な場合は有効にしてください。推奨される修正方法は、FINAL が必要なすべてのテーブルに明示的に指定することです。

設定可能な値:

• 0 - FINAL は指定したテーブルにのみ適用されます。
• 1 - JOIN の左端のテーブルの FINAL が、すべての結合先テーブルに適用されます。

​

analyzer_compatibility_join_using_top_level_identifier

JOIN USING 内のIdentifierを projection から解決するよう強制します (たとえば、SELECT a + 1 AS b FROM t1 JOIN t2 USING (b) では、t1.b = t2.b ではなく t1.a + 1 = t2.b で JOIN が実行されます) 。SELECT リスト内の部分式で定義された別名も考慮されます (たとえば、SELECT uniqExact(a + 1 AS b) FROM t1 JOIN t2 USING (b) では、t1.a + 1 = t2.b で JOIN が実行されます) 。一致する別名がトップレベルの別名ではなく SELECT リスト内の部分式で定義されている場合、そのクエリでは並列レプリカが無効になります。リモートサーバーに送信されるクエリ (Distributed テーブル、remote テーブル関数) では、リモートサーバー上でIdentifierをまったく解決できない場合にのみ、そのクエリは例外で拒否されます。別名が左テーブルの実際のカラムを隠している場合、リモートサーバーは代わりにそのカラムで JOIN を実行するため、結果がローカル実行と異なる可能性があります。

​

analyzer_compatibility_multiple_joins_qualify_column_names

有効にすると、クエリの FROM 句に2つ以上の JOIN が含まれる場合 (カンマ区切りのテーブルは数えますが、ARRAY JOIN は数えません) 、アナライザは旧アナライザの複数 JOIN の書き換えと同様に結果カラムに名前を付けます。

• *、<table>.*、または COLUMNS('<regexp>') の展開によって生成されるカラムには、<alias-or-table>.<column> 形式の名前が付けられます (修飾子には、テーブル式に別名があればその別名が使用され、なければデータベース名を除いたテーブル名、さらにそれもなければ CTE 名が使用されます。別名のない結合サブクエリのカラムは修飾されません) 。単一のテーブル式ではなく JOIN 自体に属するため、修飾なしの名前を維持するカラムには2種類あります。ARRAY JOIN によって生成されるカラムと、JOIN ... USING によってマージされるキーです。したがって、SELECT ll.arr や SELECT ll.k のような外部参照は、これら2つの形式では解決されません。
• 識別子リスト形式の COLUMNS(col1, col2) はマッチャーの展開ではありません。各カラムは識別子に記述された名前をそのまま維持するため、COLUMNS(x) は x を生成し、COLUMNS(a.x) は a.x を生成します。
• SELECT リスト内の別名なしのカラム参照は、記述された名前をそのまま維持します (例: SELECT a.x は、x が曖昧でない場合でも a.x という名前のカラムを生成します) 。

これにより、修飾名でこうしたカラムを参照する外部クエリが機能するようになります。例:

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

アナライザが有効な場合にのみ適用されます (enable_analyzer = 1) 。

​

analyzer_compatibility_prefer_alias_over_subcolumn

b.id のような複合Identifierが、エイリアス b を持つテーブルのカラム id としても、別のカラムの Tuple サブカラム b.id としても解釈できる場合は、エイリアスのプレフィックスとしての解釈 (b のカラム id) を優先します。デフォルトでは、アナライザはサブカラムを優先します。以前のアナライザの解決に合わせるには、これを有効にします。