CREATE POLICY <refpurpose>define a new row-level security policy for a table</refpurpose> — テーブルに新しい行単位のセキュリティポリシーを定義する
CREATE POLICYnameONtable_name[ AS { PERMISSIVE | RESTRICTIVE } ] [ FOR { ALL | SELECT | INSERT | UPDATE | DELETE } ] [ TO {role_name| PUBLIC | CURRENT_ROLE | CURRENT_USER | SESSION_USER } [, ...] ] [ USING (using_expression) ] [ WITH CHECK (check_expression) ]
The <command>CREATE POLICY</command> command defines a new row-level
security policy for a table. Note that row-level security must be
enabled on the table (using <command>ALTER TABLE ... ENABLE ROW LEVEL
SECURITY</command>) in order for created policies to be applied.
CREATE POLICYはテーブルに新しい行単位のセキュリティポリシーを定義します。
作成したポリシーを適用するには、（ALTER TABLE ... ENABLE ROW LEVEL SECURITYを使って）テーブルの行単位セキュリティを有効にしなければならないことに注意して下さい。
A policy grants the permission to select, insert, update, or delete rows
that match the relevant policy expression. Existing table rows are
checked against the expression specified in <literal>USING</literal>,
while new rows that would be created via <literal>INSERT</literal>
or <literal>UPDATE</literal> are checked against the expression specified
in <literal>WITH CHECK</literal>. When a <literal>USING</literal>
expression returns true for a given row then that row is visible to the
user, while if false or null is returned then the row is not visible.
When a <literal>WITH CHECK</literal> expression returns true for a row
then that row is inserted or updated, while if false or null is returned
then an error occurs.
ポリシーは、それを定義する式にマッチした行をselect/insert/update/deleteする権限を与えます。
テーブルの既存の行はUSINGで指定した式によって検査されます。
INSERTまたはUPDATEによって作成される新しい行はWITH CHECKで指定した式によって検査されます。
ある行についてUSING式がtrueを返した場合、その行はユーザに可視となりますが、falseまたはnullを返した場合は不可視となります。
行に対してWITH CHECK式がtrueを返した場合、その行は挿入または更新されますが、falseまたはnullを返した場合はエラーが発生します。
For <command>INSERT</command>, <command>UPDATE</command>, and
<command>MERGE</command> statements,
<literal>WITH CHECK</literal> expressions are enforced after
<literal>BEFORE</literal> triggers are fired, and before any actual data
modifications are made. Thus a <literal>BEFORE ROW</literal> trigger may
modify the data to be inserted, affecting the result of the security
policy check. <literal>WITH CHECK</literal> expressions are enforced
before any other constraints.
INSERT文、UPDATE文およびMERGEでは、BEFOREトリガーが実行された後で、かつ、実際のデータ更新が行われるより前にWITH CHECK式が実行されます。
従って、BEFORE ROWトリガーは挿入されるデータを変更する場合があり、これはセキュリティポリシーの検査の結果に影響を与えます。
WITH CHECK式は他のいかなる制約よりも前に実行されます。
Policy names are per-table. Therefore, one policy name can be used for many different tables and have a definition for each table which is appropriate to that table. ポリシー名はテーブル毎につけられます。 従って、1つのポリシー名を多くの異なるテーブルに使うことができます。 また、その定義は各テーブル毎に異なった、適切な内容にできます。
Policies can be applied for specific commands or for specific roles. The default for newly created policies is that they apply for all commands and roles, unless otherwise specified. Multiple policies may apply to a single command; see below for more details. <xref linkend="sql-createpolicy-summary"/> summarizes how the different types of policy apply to specific commands. ポリシーは特定のコマンドまたは特定のロールに対して適用することができます。 新しく作成するポリシーのデフォルトは、特に指定しなければ、すべてのコマンドとロールに適用、となっています。 複数のポリシーを単一のコマンドに適用できます。 更なる詳細は以下を参照ください。 表 292に、どのようにして、特定のコマンドに異なるタイプのポリシーが適用されるかがまとめられています。
For policies that can have both <literal>USING</literal>
and <literal>WITH CHECK</literal> expressions (<literal>ALL</literal>
and <literal>UPDATE</literal>), if no <literal>WITH CHECK</literal>
expression is defined, then the <literal>USING</literal> expression will be
used both to determine which rows are visible (normal
<literal>USING</literal> case) and which new rows will be allowed to be
added (<literal>WITH CHECK</literal> case).
USING式とWITH CHECK式の両方を持つことができるポリシー（ALLとUPDATE）についてWITH CHECK式が定義されていない場合、どの行が可視であるかの決定（通常のUSINGの対象）と新しい行のどれが追加可能であるかの決定（WITH CHECKの対象）の両方でUSING式が使用されます。
If row-level security is enabled for a table, but no applicable policies exist, a <quote>default deny</quote> policy is assumed, so that no rows will be visible or updatable. テーブルの行単位セキュリティが有効で、適用可能なポリシーが存在しない場合、「デフォルト拒否」のポリシーが適用され、すべての行が不可視で更新不能になります。
nameThe name of the policy to be created. This must be distinct from the name of any other policy for the table. 作成するポリシーの名前です。 同じテーブルの他のポリシーとは異なる名前でなければなりません。
table_nameThe name (optionally schema-qualified) of the table the policy applies to. ポリシーが適用されるテーブルの名前（スキーマ修飾可）です。
PERMISSIVESpecify that the policy is to be created as a permissive policy. All permissive policies which are applicable to a given query will be combined together using the Boolean <quote>OR</quote> operator. By creating permissive policies, administrators can add to the set of records which can be accessed. Policies are permissive by default. 作成するポリシーが許容(permissive)ポリシーであることを指定します。 問い合わせに適用可能なすべての許容ポリシーは論理演算子「OR」を使って結合されます。 許容ポリシーを作成することで、管理者はアクセス可能なレコード集合を追加することができます。 デフォルトではポリシーは許容ポリシーです。
RESTRICTIVESpecify that the policy is to be created as a restrictive policy. All restrictive policies which are applicable to a given query will be combined together using the Boolean <quote>AND</quote> operator. By creating restrictive policies, administrators can reduce the set of records which can be accessed as all restrictive policies must be passed for each record. 作成するポリシーが制限(restrictive)ポリシーであることを指定します。 問い合わせに適用可能なすべての制限ポリシーは論理演算子「AND」と使って結合されます。 各行についてすべての制限ポリシーを満たさなければならなくなるため、制限ポリシーを作成することで、管理者はアクセス可能なレコード集合を減らすことができます。
Note that there needs to be at least one permissive policy to grant access to records before restrictive policies can be usefully used to reduce that access. If only restrictive policies exist, then no records will be accessible. When a mix of permissive and restrictive policies are present, a record is only accessible if at least one of the permissive policies passes, in addition to all the restrictive policies. 制限ポリシーを有効に使ってアクセスを制限できるようにする前に、レコードへのアクセスを許可する許容ポリシーが少なくとも1つ必要であることに注意してください。 制限ポリシーだけしか存在しない場合、レコードにアクセスすることはできません。 許容ポリシーと制限ポリシーが混在している場合、少なくとも1つの許容ポリシーを満たし、さらに、すべての制限ポリシーを満たしている場合のみレコードにアクセスできます。
command
The command to which the policy applies. Valid options are
<command>ALL</command>, <command>SELECT</command>,
<command>INSERT</command>, <command>UPDATE</command>,
and <command>DELETE</command>.
<command>ALL</command> is the default.
See below for specifics regarding how these are applied.
ポリシーが適用されるコマンドです。
有効なオプションはALL、SELECT、INSERT、UPDATE、DELETEです。
デフォルトはALLです。
これらがどのように適用されるかの詳細は以下を参照して下さい。
role_name
The role(s) to which the policy is to be applied. The default is
<literal>PUBLIC</literal>, which will apply the policy to all roles.
ポリシーが適用されるロールです。
デフォルトはPUBLICで、すべてのロールに対してポリシーが適用されます。
using_expression
Any <acronym>SQL</acronym> conditional expression (returning
<type>boolean</type>). The conditional expression cannot contain
any aggregate or window functions. This expression will be added
to queries that refer to the table if row-level security is enabled.
Rows for which the expression returns true will be visible. Any
rows for which the expression returns false or null will not be
visible to the user (in a <command>SELECT</command>), and will not be
available for modification (in an <command>UPDATE</command>
or <command>DELETE</command>). Such rows are silently suppressed; no error
is reported.
任意のSQL条件式（戻り値はboolean）です。
条件式に集約関数やウィンドウ関数を含めることはできません。
行単位セキュリティが有効なときは、テーブルへの問い合わせにこの式が追加されます。
この式がtrueを返す行が可視となります。
この式がfalseまたはnullを返す行は、ユーザには（SELECTにおいて）不可視となり、また（UPDATEあるいはDELETEでは）更新の対象ではなくなります。
そのような行は静かに無視され、エラーは報告されません。
check_expression
Any <acronym>SQL</acronym> conditional expression (returning
<type>boolean</type>). The conditional expression cannot contain
any aggregate or window functions. This expression will be used in
<command>INSERT</command> and <command>UPDATE</command> queries against
the table if row-level security is enabled. Only rows for which the
expression evaluates to true will be allowed. An error will be thrown
if the expression evaluates to false or null for any of the records
inserted or any of the records that result from the update. Note that
the <replaceable class="parameter">check_expression</replaceable> is
evaluated against the proposed new contents of the row, not the
original contents.
任意のSQL条件式（戻り値はboolean）です。
条件式に集約関数やウィンドウ関数を含めることはできません。
この式は、行単位セキュリティが有効な場合に、そのテーブルに対するINSERTおよびUPDATEの問い合わせで使用されます。
この式の評価がtrueになる行のみが許されます。
挿入されるレコード、あるいは更新の結果のレコードでこの式の評価がfalseまたはnullになるものについては、エラーが発生します。
check_expressionは元の内容ではなく、予定される更新の後の新しい内容に対して評価されることに注意してください。
ALL #
Using <literal>ALL</literal> for a policy means that it will apply
to all commands, regardless of the type of command. If an
<literal>ALL</literal> policy exists and more specific policies
exist, then both the <literal>ALL</literal> policy and the more
specific policy (or policies) will be applied.
Additionally, <literal>ALL</literal> policies will be applied to
both the selection side of a query and the modification side, using
the <literal>USING</literal> expression for both cases if only
a <literal>USING</literal> expression has been defined.
ポリシーにALLを使うのは、そのポリシーはコマンドの種類に関係なく、すべてのコマンドに適用されるという意味になります。
ALLのポリシーと特定のコマンドに対するポリシーの両方が存在する場合、ALLのポリシーと特定のコマンドに対するポリシーの両方が適用されます。
さらにALLのポリシーは、問い合わせの選択側と更新側の両方で適用されます。
このとき、USING式だけが定義されていたら、両方の場合についてUSING式を使用します。
As an example, if an <literal>UPDATE</literal> is issued, then the
<literal>ALL</literal> policy will be applicable both to what the
<literal>UPDATE</literal> will be able to select as rows to be
updated (applying the <literal>USING</literal> expression),
and to the resulting updated rows, to check if they are permitted
to be added to the table (applying the <literal>WITH CHECK</literal>
expression, if defined, and the <literal>USING</literal> expression
otherwise). If an <command>INSERT</command>
or <command>UPDATE</command> command attempts to add rows to the
table that do not pass the <literal>ALL</literal>
policy's <literal>WITH CHECK</literal> expression, the entire
command will be aborted.
例えばUPDATEが実行されるとき、ALLのポリシーは、UPDATEが更新対象の行として選択できる行（USING式が適用されます）と、UPDATE文の結果としてできる行がテーブルに追加できるかどうかの検証（WITH CHECKが定義されていれば、それが適用され、なければUSING式が適用されます）の両方で適用可能です。
INSERTまたはUPDATEコマンドがALLのWITH CHECK式に反する行をテーブルに追加しようとした場合、コマンド全体が中止されます。
SELECT #
Using <literal>SELECT</literal> for a policy means that it will apply
to <literal>SELECT</literal> queries and whenever
<literal>SELECT</literal> permissions are required on the relation the
policy is defined for. The result is that only those records from the
relation that pass the <literal>SELECT</literal> policy will be
returned during a <literal>SELECT</literal> query, and that queries
that require <literal>SELECT</literal> permissions, such as
<literal>UPDATE</literal>, will also only see those records
that are allowed by the <literal>SELECT</literal> policy.
A <literal>SELECT</literal> policy cannot have a <literal>WITH
CHECK</literal> expression, as it only applies in cases where
records are being retrieved from the relation.
ポリシーにSELECTを使うのは、そのポリシーはSELECTの問い合わせの他に、そのポリシーが定義されているリレーションに対してSELECT権限が必要な時は常に適用されるという意味になります。
その結果、SELECT問い合わせでは、SELECTポリシーに適うレコードだけが返されます。
また、UPDATEなどSELECT権限が必要な問い合わせでも、SELECTポリシーによって許可されるレコードだけが見えます。
SELECTポリシーはリレーションからレコードを取り出す場合にしか適用されないので、WITH CHECK式を持つことはできません。
INSERT #
Using <literal>INSERT</literal> for a policy means that it will apply
to <literal>INSERT</literal> commands and <literal>MERGE</literal>
commands that contain <literal>INSERT</literal> actions.
Rows being inserted that do
not pass this policy will result in a policy violation error, and the
entire <literal>INSERT</literal> command will be aborted.
An <literal>INSERT</literal> policy cannot have
a <literal>USING</literal> expression, as it only applies in cases
where records are being added to the relation.
ポリシーにINSERTを使うことは、そのポリシーはINSERTコマンドとINSERTの動作を含むMERGEコマンドに適用するという意味になります。
このポリシーに反する行を挿入しようとすると、ポリシー違反エラーを起こし、INSERTコマンド全体が中止されます。
INSERTポリシーはリレーションにレコードを追加する場合にしか適用されないため、USING式を持つことはできません。
Note that <literal>INSERT</literal> with <literal>ON CONFLICT DO
UPDATE</literal> checks <literal>INSERT</literal> policies'
<literal>WITH CHECK</literal> expressions only for rows appended
to the relation by the <literal>INSERT</literal> path.
ON CONFLICT DO UPDATEのあるINSERTでは、INSERTポリシーのWITH CHECK式について、INSERTの部分でリレーションに追加されるすべての行についてのみ確認することに注意してください。
UPDATE #
Using <literal>UPDATE</literal> for a policy means that it will apply
to <literal>UPDATE</literal>, <literal>SELECT FOR UPDATE</literal>
and <literal>SELECT FOR SHARE</literal> commands, as well as
auxiliary <literal>ON CONFLICT DO UPDATE</literal> clauses of
<literal>INSERT</literal> commands.
<literal>MERGE</literal> commands containing <literal>UPDATE</literal>
actions are affected as well. Since <literal>UPDATE</literal>
involves pulling an existing record and replacing it with a new
modified record, <literal>UPDATE</literal>
policies accept both a <literal>USING</literal> expression and
a <literal>WITH CHECK</literal> expression.
The <literal>USING</literal> expression determines which records
the <literal>UPDATE</literal> command will see to operate against,
while the <literal>WITH CHECK</literal> expression defines which
modified rows are allowed to be stored back into the relation.
ポリシーにUPDATEを使うことは、そのポリシーはUPDATEコマンド、SELECT FOR UPDATEコマンド、SELECT FOR SHAREコマンド、および補助的にINSERTコマンドのON CONFLICT DO UPDATE句で適用されるという意味になります。
UPDATE動作を含むMERGEコマンドも影響を受けます。
UPDATEは既存のレコードを取り出すことと、レコードを新しい修正されたレコードで置換することが含まれるので、UPDATEポリシーはUSING式とWITH CHECK式の両方を受け付けます。
USING式はUPDATEコマンドが操作の対象としてどのレコードを見ることができるかを決めるのに使われます。
一方でWITH CHECKはどの修正した行をリレーションに戻すことができるかを定義します。
Any rows whose updated values do not pass the
<literal>WITH CHECK</literal> expression will cause an error, and the
entire command will be aborted. If only a <literal>USING</literal>
clause is specified, then that clause will be used for both
<literal>USING</literal> and <literal>WITH CHECK</literal> cases.
更新後の値がWITH CHECK式に反する行があればエラーを起こし、コマンド全体が中止されます。
USING句だけが指定されていた場合は、それがUSINGとWITH CHECKの両方に対して使用されます。
Typically an <literal>UPDATE</literal> command also needs to read
data from columns in the relation being updated (e.g., in a
<literal>WHERE</literal> clause or a <literal>RETURNING</literal>
clause, or in an expression on the right hand side of the
<literal>SET</literal> clause). In this case,
<literal>SELECT</literal> rights are also required on the relation
being updated, and the appropriate <literal>SELECT</literal> or
<literal>ALL</literal> policies will be applied in addition to
the <literal>UPDATE</literal> policies. Thus the user must have
access to the row(s) being updated through a <literal>SELECT</literal>
or <literal>ALL</literal> policy in addition to being granted
permission to update the row(s) via an <literal>UPDATE</literal>
or <literal>ALL</literal> policy.
通常は、UPDATEコマンドは更新対象のリレーションの列からデータを読む必要もあります（例えば、WHERE句の中、RETURNING句、あるいはSET句の右辺の式の中）。
この場合、更新対象のリレーションのSELECT権限も必要となり、UPDATEポリシーに加えて、適切なSELECTまたはALLポリシーも適用されます。
従って、ユーザはUPDATEまたはALLポリシーによって、行を更新する権限を付与されているのに加えて、SELECTまたはALLポリシーによって、更新対象の行にアクセスできなければなりません。
When an <literal>INSERT</literal> command has an auxiliary
<literal>ON CONFLICT DO UPDATE</literal> clause, if the
<literal>UPDATE</literal> path is taken, the row to be updated is
first checked against the <literal>USING</literal> expressions of
any <literal>UPDATE</literal> policies, and then the new updated row
is checked against the <literal>WITH CHECK</literal> expressions.
Note, however, that unlike a standalone <literal>UPDATE</literal>
command, if the existing row does not pass the
<literal>USING</literal> expressions, an error will be thrown (the
<literal>UPDATE</literal> path will <emphasis>never</emphasis> be silently
avoided).
INSERTコマンドに補助的なON CONFLICT DO UPDATE句があり、UPDATEの部分が使われるとき、更新対象の行についてまず、すべてのUPDATEポリシーのUSING式が検査され、次いで、更新された新しい行がWITH CHECK式が検査されます。
しかし、単独のUPDATEコマンドとは異なり、既存の行がUSING式を満たさないときは、エラーが発生します（UPDATEの部分が警告なしに回避されることは決してありません）。
DELETE #
Using <literal>DELETE</literal> for a policy means that it will apply
to <literal>DELETE</literal> commands. Only rows that pass this
policy will be seen by a <literal>DELETE</literal> command. There can
be rows that are visible through a <literal>SELECT</literal> that are
not available for deletion, if they do not pass the
<literal>USING</literal> expression for
the <literal>DELETE</literal> policy.
ポリシーにDELETEを使うのは、そのポリシーはDELETEコマンドに適用されるという意味になります。
ポリシーを満たす行だけがDELETEコマンドから見えます。
SELECTでは見えるけれど、削除の対象ではない、という行もあり得ます。
それらの行がDELETEポリシーのUSING式を満たさない場合です。
In most cases a <literal>DELETE</literal> command also needs to read
data from columns in the relation that it is deleting from (e.g.,
in a <literal>WHERE</literal> clause or a
<literal>RETURNING</literal> clause). In this case,
<literal>SELECT</literal> rights are also required on the relation,
and the appropriate <literal>SELECT</literal> or
<literal>ALL</literal> policies will be applied in addition to
the <literal>DELETE</literal> policies. Thus the user must have
access to the row(s) being deleted through a <literal>SELECT</literal>
or <literal>ALL</literal> policy in addition to being granted
permission to delete the row(s) via a <literal>DELETE</literal> or
<literal>ALL</literal> policy.
ほとんどの場合、DELETEコマンドは削除対象のリレーションの列からデータを読む必要もあります（例えば、WHERE句の中やRETURNING句）。
この場合、リレーション上のSELECT権限も必要となり、DELETEポリシーに加えて、適切なSELECTポリシーまたはALLポリシーも適用されます。
従って、ユーザはDELETEまたはALLポリシーによって、行を削除する権限を付与されているのに加えて、SELECTまたはALLポリシーによって、削除対象の行にアクセスできなければなりません。
A <literal>DELETE</literal> policy cannot have a <literal>WITH
CHECK</literal> expression, as it only applies in cases where
records are being deleted from the relation, so that there is no
new row to check.
DELETEポリシーはリレーションからレコードが削除される場合にしか適用されず、確認すべき新しい行はないので、WITH CHECK式を持つことはできません。
表292 コマンドタイプにより適用されるポリシー
| コマンド | SELECT/ALLポリシー | INSERT/ALLポリシー | UPDATE/ALLポリシー | DELETE/ALLポリシー | |
|---|---|---|---|---|---|
USING式 | WITH CHECK式 | USING式 | WITH CHECK式 | USING式 | |
SELECT | 既存の行 | — | — | — | — |
SELECT FOR UPDATE/SHARE | 既存の行 | — | 既存の行 | — | — |
INSERT / MERGE ... THEN INSERT | — | 新しい行 | — | — | — |
INSERT ... RETURNING | New row <footnote id="rls-select-priv"> 新しい行 [a] | 新しい行 | — | — | — |
UPDATE / MERGE ... THEN UPDATE | Existing & new rows <footnoteref linkend="rls-select-priv"/> 既存の行と新しい行 [a] | — | 既存の行 | 新しい行 | — |
DELETE | Existing row <footnoteref linkend="rls-select-priv"/> 既存の行 [a] | — | — | — | 既存の行 |
ON CONFLICT DO UPDATE | 既存の行と新しい行 | — | 既存の行 | 新しい行 | — |
[a]
If read access is required to the existing or new row (for example,
a <literal>WHERE</literal> or <literal>RETURNING</literal> clause
that refers to columns from the relation).
読み出しアクセスが既存の、あるいは新しい行（たとえば、リレーションのカラムを参照する | |||||
When multiple policies of different command types apply to the same command
(for example, <literal>SELECT</literal> and <literal>UPDATE</literal>
policies applied to an <literal>UPDATE</literal> command), then the user
must have both types of permissions (for example, permission to select rows
from the relation as well as permission to update them). Thus the
expressions for one type of policy are combined with the expressions for
the other type of policy using the <literal>AND</literal> operator.
同じコマンドに対して、異なるコマンド種別の複数のポリシーを適用する場合（例えば、UPDATEコマンドに対してはSELECTとUPDATEのポリシーが適用されます）、ユーザは両方の種別の権限（例えば、リレーションから行を検索する権限と、それを更新する権限）を持っている必要があります。
従って、ある種別のポリシーの式は、別の種別のポリシーの式とAND演算子を使って結合されます。
When multiple policies of the same command type apply to the same command,
then there must be at least one <literal>PERMISSIVE</literal> policy
granting access to the relation, and all of the
<literal>RESTRICTIVE</literal> policies must pass. Thus all the
<literal>PERMISSIVE</literal> policy expressions are combined using
<literal>OR</literal>, all the <literal>RESTRICTIVE</literal> policy
expressions are combined using <literal>AND</literal>, and the results are
combined using <literal>AND</literal>. If there are no
<literal>PERMISSIVE</literal> policies, then access is denied.
同じコマンドに対して同じコマンド種別の複数のポリシーが適用される場合、リレーションのアクセスを許可する少なくとも1つのPERMISSIVEポリシーがなければならず、さらにすべてのRESTRICTIVEポリシーを満たす必要があります。
従って、すべてのPERMISSIVEポリシー式がORを使って結合され、すべてのRESTRICTIVEポリシー式がANDを使って結合され、その結果がANDを使って結合されます。
PERMISSIVEポリシーがなければアクセスは拒絶されます。
Note that, for the purposes of combining multiple policies,
<literal>ALL</literal> policies are treated as having the same type as
whichever other type of policy is being applied.
複数のポリシーを結合するという目的において、ALLのポリシーは適用対象となっている他のすべてのポリシーと同じ種別であるとして扱われることに注意してください。
For example, in an <literal>UPDATE</literal> command requiring both
<literal>SELECT</literal> and <literal>UPDATE</literal> permissions, if
there are multiple applicable policies of each type, they will be combined
as follows:
例えば、SELECTとUPDATEの両方の権限を必要とするUPDATEコマンドにおいて、それぞれの種別の適用可能な複数のポリシーがある場合、以下のように結合されます。
expressionfrom RESTRICTIVE SELECT/ALL policy 1 ANDexpressionfrom RESTRICTIVE SELECT/ALL policy 2 AND ... AND (expressionfrom PERMISSIVE SELECT/ALL policy 1 ORexpressionfrom PERMISSIVE SELECT/ALL policy 2 OR ... ) ANDexpressionfrom RESTRICTIVE UPDATE/ALL policy 1 ANDexpressionfrom RESTRICTIVE UPDATE/ALL policy 2 AND ... AND (expressionfrom PERMISSIVE UPDATE/ALL policy 1 ORexpressionfrom PERMISSIVE UPDATE/ALL policy 2 OR ... )
You must be the owner of a table to create or change policies for it. ポリシーを作成あるいは変更するには、テーブルの所有者でなければなりません。
While policies will be applied for explicit queries against tables in the database, they are not applied when the system is performing internal referential integrity checks or validating constraints. This means there are indirect ways to determine that a given value exists. An example of this is attempting to insert a duplicate value into a column that is a primary key or has a unique constraint. If the insert fails then the user can infer that the value already exists. (This example assumes that the user is permitted by policy to insert records which they are not allowed to see.) Another example is where a user is allowed to insert into a table which references another, otherwise hidden table. Existence can be determined by the user inserting values into the referencing table, where success would indicate that the value exists in the referenced table. These issues can be addressed by carefully crafting policies to prevent users from being able to insert, delete, or update records at all which might possibly indicate a value they are not otherwise able to see, or by using generated values (e.g., surrogate keys) instead of keys with external meanings. ポリシーは、データベース内のテーブルに対する明示的な問い合わせには適用されますが、システムが内部的な参照整合性のチェックや制約の検証をしている時には適用されません。 この意味するところは、ある値が存在するかどうかを判定する間接的な方法がある、ということです。 その例の1つは、主キーあるいは一意制約のある列に重複する値を挿入しようとすることです。 挿入に失敗すれば、その値が既に存在すると推定することができます。 （この例では、ユーザが見ることができないレコードを挿入することがポリシーにより許されていると仮定しています。） 別の例は、あるテーブルへの挿入は許されているが、そのテーブルが別の隠されているテーブルを参照している、という場合です。 参照元のテーブルに値を挿入することで、値の存在が判断できます。 この場合、挿入の成功はその値が参照先のテーブルに存在することを示唆します。 これらの問題は、見ることができない値を示唆するかもしれないようなレコードの挿入、削除、更新が全くできないように注意深くポリシーを設計するか、あるいは外部的な意味を持つキーの代わりに生成された値（例：代理キー）を使うことで解決できます。
Generally, the system will enforce filter conditions imposed using
security policies prior to qualifications that appear in user queries,
in order to prevent inadvertent exposure of the protected data to
user-defined functions which might not be trustworthy. However,
functions and operators marked by the system (or the system
administrator) as <literal>LEAKPROOF</literal> may be evaluated before
policy expressions, as they are assumed to be trustworthy.
一般に、システムは問い合わせに記述される制限より前に、セキュリティポリシーを使ったフィルター条件を実行します。
これは守られるべきデータが信頼できないかもしれないユーザ定義関数に偶然に意図せずに渡されることを防ぐためです。
しかし、システム（またはシステム管理者）によってLEAKPROOFであるとされた関数や演算子については、信頼できるとみなして良いので、ポリシー式より先に評価される場合があります。
Since policy expressions
are added to the user's query directly, they will be run with the rights of
the user running the overall query. Therefore, users who are using a given
policy must be able to access any tables or functions referenced in the
expression or they will simply receive a permission denied error when
attempting to query the table that has row-level security enabled.
This does not change how views
work, however. As with normal queries and views, permission checks and
policies for the tables which are referenced by a view will use the view
owner's rights and any policies which apply to the view owner, except if
the view is defined using the <literal>security_invoker</literal> option
(see <link linkend="sql-createview"><command>CREATE VIEW</command></link>).
ポリシーの式はユーザの問い合わせに直接追加されるため、式は問い合わせ全体を実行しているユーザの権限によって実行されます。
そのため、あるポリシーを使用するユーザは、その式が参照しているすべてのテーブルおよび関数にアクセスできる必要があります。
そうでなければ、行単位セキュリティが有効になっているテーブルに問い合わせをしようとしたときに、単に権限なしのエラーを受け取ります。
しかし、これによってビューの動作が変わることはありません。
通常の問い合わせおよびビューと同じく、ビューによって参照されるテーブルに対する権限の確認とポリシーは、ビューの所有者の権限およびビューの所有者に適用されるポリシーを利用します。ただし、ビューがsecurity_invokerオプション(CREATE VIEWを参照)を使って定義されている場合を除きます。
No separate policy exists for <command>MERGE</command>. Instead, the policies
defined for <command>SELECT</command>, <command>INSERT</command>,
<command>UPDATE</command>, and <command>DELETE</command> are applied
while executing <command>MERGE</command>, depending on the actions that are
performed.
MERGEに個別のポリシーは存在しません。
その代わり、SELECT、INSERT、UPDATEおよびDELETEに定義されたポリシーが、実行される動作に応じてMERGEの実行時に適用されます。
Additional discussion and practical examples can be found in <xref linkend="ddl-rowsecurity"/>. 更なる詳細と実践的な例については5.8に記述されています。
<command>CREATE POLICY</command> is a <productname>PostgreSQL</productname>
extension.
CREATE POLICYはPostgreSQLの拡張です。