Skip to main content
これらの設定は 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_cte_redefinition

1 つの WITH 句内で、共通テーブル式 (Common Table Expression) の名前を複数回定義できるようにします。このような名前への参照は、その時点で解決中ではない最新の定義に束縛されます。つまり、再定義の中では同じ名前の直前の定義を参照でき、クエリ本体は最後の定義を参照します。これは、後の定義が前の定義を暗黙的に上書きしていた、v24.3 より前の ClickHouse のクエリ解析と同じ挙動です。ただし、1 つのパターンでのみ旧来の解析と挙動が異なります。ある名前の 2 つの定義の間で宣言された CTE も最後の定義に束縛されますが、旧来の解析では、その宣言位置から参照可能だった定義に束縛されていました。デフォルトでは、再定義は MULTIPLE_EXPRESSIONS_FOR_ALIAS エラーで拒否されます。MATERIALIZED として宣言された CTE および WITH RECURSIVE 句内の CTE は、この設定が有効な場合でも再定義できません。 設定可能な値:
  • 0 - CTE 名は WITH 句内で 1 回しか定義できません。
  • 1 - CTE 名の後の定義が前の定義を上書きします。

​
analyzer_compatibility_allow_non_aggregate_in_having

有効にすると、アナライザは NOT_AN_AGGREGATE を返す代わりに、非集約の AND 条件を HAVING から WHERE に移動する従来の動作を再現します。デフォルトでは標準準拠の拒否動作が使われます。これは、ClickHouse が v24.3 より前に使用していたクエリ解析で暗黙的に受け入れられていたクエリのための移行支援です。集約関数、grouping、または非決定論的関数を含む条件は HAVING に残ります。いずれかの条件にウィンドウ関数または stateful function (たとえば rowNumberInBlock) が含まれている場合、書き換えは HAVING 全体で無効になり、従来のクエリ解析の動作と一致します。また、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 が実行されます) 。WITH 句、SELECT リスト内の部分式、その他の句など、クエリ内の別の場所で定義された別名も考慮されます (たとえば、WITH a + 1 AS b SELECT count() FROM t1 JOIN t2 USING (b) や SELECT uniqExact(a + 1 AS b) FROM t1 JOIN t2 USING (b) では、t1.a + 1 = t2.b で JOIN が実行されます) 。複数の JOIN を含むクエリでは、USING のIdentifierを別名から解決するのは最も外側の JOIN のみです。内側の 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 という名前のカラムを生成します) 。
これにより、修飾名でこうしたカラムを参照する外部クエリが機能するようになります。例:

​
analyzer_compatibility_prefer_alias_over_subcolumn

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