Skip to main content
行ポリシーを作成します。これは、ユーザーがテーブルから読み取れる行を決定するためのフィルターです。
行ポリシーが有効なのは、読み取り専用アクセスを持つユーザーに対してのみです。ユーザーがテーブルを変更したり、テーブル間でパーティションをコピーできたりする場合、行ポリシーによる制限は意味をなさなくなります。
構文:
ParserRowPolicyNames3つのパッキング形式を受け入れます (完全なデカルト積ではありません) 。
  1. 複数の名前、1つの対象pol1, pol2 ON table1 は、列挙した各名前をその1つのテーブル (または db.*) に作成します。
  2. 1つの名前、複数の対象pol1 ON table1, table2 は、同じ短縮名を列挙した各対象に作成します。
  3. 混在したペアp1 ON t1, p2 ON t2 は、各名前を対応する対象にのみ作成します。
複数名のリストを、1つのグループ内で複数テーブルの ON リストと組み合わせることはできません。p1, p2 ON t1, t2 は拒否されます。複数名グループの後に、同じステートメント内で別のカンマ区切りの name ON target グループを追加することもできません。 省略可能な ON CLUSTER は、ステートメント全体に適用されます (指定できるクラスター名は1つです) 。ClickHouse では、単一の作成操作にまとめられたポリシー名ごとに異なる ON CLUSTER を指定することはできません。異なるクラスターにポリシーを作成する必要がある場合は、個別の CREATE ROW POLICY ステートメントを実行してください。

複数の名前とテーブル

有効な例:
無効:

USING 句

行を絞り込むための条件を指定できます。ある行に対する条件の評価結果が非ゼロの場合、その行はユーザーに表示されます。

TO 句

TO 句では、このポリシーの適用対象となるユーザーとロールの一覧を指定できます。たとえば、CREATE ROW POLICY ... TO accountant, john@localhost のように指定します。 キーワード ALL は、現在のユーザーを含むすべての ClickHouse ユーザーを意味します。キーワード ALL EXCEPT を使うと、全ユーザーの一覧から一部のユーザーを除外できます。たとえば、CREATE ROW POLICY ... TO ALL EXCEPT accountant, john@localhost のように指定します。

AS 句

同じユーザーに対して、同じテーブルに複数のポリシーを同時に有効化できます。そのため、複数のポリシーの条件を組み合わせる方法が必要です。 デフォルトでは、ポリシーはブール演算子 OR を使って組み合わせられます。たとえば、次のポリシーです。
ユーザー peterb=1 または c=2 のいずれかを満たす行を参照できるようにします。 AS 句は、ポリシーを他のポリシーとどのように組み合わせるかを指定します。ポリシーには permissive と restrictive の 2 種類があります。デフォルトではポリシーは permissive であり、これはブール演算子 OR を使用して組み合わせられることを意味します。 別の方法として、ポリシーを restrictive として定義することもできます。restrictive ポリシーは、ブール演算子 AND を使用して組み合わせられます。 一般的な式は次のとおりです。
たとえば、次のようなポリシーがあります。
ユーザー peter が行を参照できるのは、b=1 かつ c=2 の両方を満たす場合に限られます。 データベースポリシーは、テーブルポリシーと組み合わせて適用されます。 たとえば、次のポリシーです。
ユーザー petertable1 の行を参照できるのは、b=1 かつ c=2 の場合だけです。ただし、 mydb 内の他のテーブルには、そのユーザーに対して b=1 のポリシーのみが適用されます。

Distributed テーブルとリモートバックエンドテーブル

行ポリシーは、テーブルデータが実際に読み取られる場所で行をフィルタリングします。Distributed テーブルや、それをラップするテーブル (たとえば、ターゲットが Distributed の materialized view) のように、読み取りをリモートサーバーに委譲するテーブルは、クエリテキストをリモートサーバーに送信するだけであるため、リモートでの読み取りにポリシーのフィルターを適用できません。フィルターが暗黙的に削除されるのを防ぐため、ポリシーの適用対象となるユーザーがこのようなテーブルに対して実行するクエリは、ILLEGAL_PREWHERE エラーで拒否されます。 代わりに、各リモートサーバー上の基盤となるローカルテーブルにポリシーを定義してください。送信されたクエリがそれらを読み取る際に、そこでポリシーが適用されます。
これは、デフォルトであるクエリのテキスト送信時に機能します。serialize_query_plan = 1 を指定すると、イニシエーターは代わりに構築済みの読み取りプランを送信します。このようなプランを実行するリモートサーバーは独自の行ポリシーを適用しないため、local_table 上の Distributed テーブルを読み取ると、フィルタリングされていない行が返されます。行ポリシーを適用する必要があるユーザーには、serialize_query_plan = 0 を使用してください。issue #112891 を参照してください。

ON CLUSTER 句

クラスター全体に対して行ポリシーを作成できます。詳しくは分散DDLを参照してください。これにより、クラスター内のすべてのサーバー上のローカルテーブルにポリシーを簡単に作成できます。

CREATE ROW POLICY filter1 ON mydb.mytable USING a<1000 TO accountant, john@localhost CREATE ROW POLICY filter2 ON mydb.mytable USING a<1000 AND b=5 TO ALL EXCEPT mira CREATE ROW POLICY filter3 ON mydb.mytable USING 1 TO admin CREATE ROW POLICY filter4 ON mydb.* USING 1 TO admin
最終更新日 2026年8月14日