CREATE POLICY — 为表定义新的行级安全策略
CREATE POLICYnameONtable_name[ AS { PERMISSIVE | RESTRICTIVE } ] [ FOR { ALL | SELECT | INSERT | UPDATE | DELETE } ] [ TO {role_name| PUBLIC | CURRENT_USER | SESSION_USER } [, ...] ] [ USING (using_expression) ] [ WITH CHECK (check_expression) ]
CREATE POLICY命令为一个表定义一条新的行级 安全性策略。请注意，必须先在该表上启用行级安全性（使用 ALTER TABLE ... ENABLE ROW LEVEL SECURITY）， 已创建的策略才会被应用。
策略授予选择、插入、更新或删除符合相应策略表达式的行的权限。使用USING中指定的表达式检查现有表行，而使用WITH CHECK中指定的表达式检查通过INSERT或UPDATE创建的新行。当USING表达式对给定行返回 true 时，该行对用户可见；如果返回 false 或 null，则该行不可见。当WITH CHECK表达式对某行返回 true 时，该行会被插入或更新；如果返回 false 或 null，则发生错误。
对于INSERT和UPDATE语句，会在触发BEFORE触发器之后、进行任何实际数据修改之前强制执行WITH CHECK表达式。因此，BEFORE ROW触发器可能会修改要插入的数据，从而影响安全策略检查的结果。WITH CHECK表达式会在任何其他约束之前强制执行。
策略名称按表区分。因此，同一个策略名可以用于许多不同的表，并且在 每个表上都可以有适合该表的定义。
策略可以针对特定命令或特定角色应用。除非另有指定，新建策略默认 适用于所有命令和角色。多个策略可以应用于同一命令；更多细节见下文。 Table 272总结了不同类型的策略如何应用于 特定命令。
对于既可以具有USING又可以具有 WITH CHECK表达式的策略（ALL 和UPDATE），如果未定义 WITH CHECK表达式，那么USING 表达式将同时用于决定哪些行可见（普通USING情形） 以及允许写入哪些新行（WITH CHECK情形）。
如果某个表启用了行级安全性，但不存在适用的策略，则会假定存在一条 “默认拒绝”策略，因此没有任何行可见或可更新。
name要创建的策略名称。它必须不同于该表上任何其他策略的名称。
table_name该策略适用的表的名称（可选模式限定）。
PERMISSIVE指定将该策略创建为宽松策略。适用于给定查询的所有宽松策略都会 使用布尔“OR”操作符组合在一起。通过创建宽松策略， 管理员可以扩大可访问行的集合。策略默认是宽松的。
RESTRICTIVE指定将该策略创建为限制性策略。适用于给定查询的所有限制性策略都会 使用布尔“AND”操作符组合在一起。通过创建限制性策略， 管理员可以缩小可访问行的集合，因为每一行都必须通过所有限制性 策略。
请注意，要让限制性策略能够有效缩小访问范围，必须先至少有一条 宽松策略授予对行的访问。如果只存在限制性策略，则没有任何行 可访问。当宽松策略和限制性策略混合存在时，只有在至少一条宽松 策略通过且所有限制性策略也都通过时，某一行才可访问。
command该策略适用的命令。有效选项是 ALL、SELECT、 INSERT、UPDATE 和DELETE。ALL是默认值。 有关这些策略如何应用的细节见下文。
role_name该策略适用的角色（或多个角色）。默认是PUBLIC， 即对所有角色应用该策略。
using_expression任何SQL条件表达式（返回boolean）。条件表达式不能包含聚合函数或窗口函数。如果启用行级安全性，该表达式会添加到引用该表的查询中。表达式返回 true 的行将对用户可见。表达式返回 false 或 null 的任何行对用户都不可见（在SELECT中），也不能被修改（在UPDATE或DELETE中）。这类行会被静默抑制，不会报告错误。
check_expression任何SQL条件表达式（返回boolean）。条件表达式不能包含聚合函数或窗口函数。如果启用行级安全性，该表达式会用于针对该表的INSERT和UPDATE查询。只有表达式计算结果为 true 的行才会被允许。如果对于任何插入的记录或更新产生的任何记录，表达式计算结果为 false 或 null，则会抛出错误。请注意，check_expression是针对行预计的新内容计算的，而不是针对原始内容。
ALL #对策略使用ALL意味着无论命令类型如何，该策略都适用于所有命令。如果存在ALL策略且还存在更具体的策略，则ALL策略和更具体的策略（或多个策略）都会被应用。此外，ALL策略会同时应用于查询的选择端和修改端，并在两端使用USING表达式（如果只定义了USING表达式）。
例如，如果发出UPDATE，则ALL策略既适用于UPDATE能够选择哪些行进行更新（应用USING表达式），也适用于更新后的行，以检查它们是否允许被添加回表中（如果定义了WITH CHECK表达式则应用该表达式，否则应用USING表达式）。如果INSERT或UPDATE命令尝试向表中添加不通过ALL策略的WITH CHECK表达式的行，则整个命令都会中止。
SELECT #对策略使用SELECT意味着该策略适用于SELECT查询，以及在策略所定义的关系上需要SELECT权限的任何时候。因此，在SELECT查询期间，只会返回关系中通过SELECT策略的记录；需要SELECT权限的查询（例如UPDATE）也只能看到被SELECT策略允许的记录。SELECT策略不能有WITH CHECK表达式，因为它只适用于从关系中检索记录的情况。
INSERT #对策略使用INSERT意味着该策略适用于INSERT命令。插入的不通过该策略的行会导致策略违反错误，并且整个INSERT命令都会中止。INSERT策略不能有USING表达式，因为它只适用于向关系添加记录的情况。
请注意，带有ON CONFLICT DO UPDATE的INSERT只会为通过INSERT路径添加到关系中的行检查INSERT策略的WITH CHECK表达式。
UPDATE #对策略使用UPDATE意味着该策略适用于UPDATE、SELECT FOR UPDATE和SELECT FOR SHARE命令，以及INSERT命令的辅助ON CONFLICT DO UPDATE子句。由于UPDATE涉及取出一条现有记录并用新的修改后记录替换它，UPDATE策略同时接受USING表达式和WITH CHECK表达式。USING表达式决定UPDATE命令将看到哪些记录并对其操作，而WITH CHECK表达式定义允许将哪些修改后的行存回关系。
任何更新后的值未通过WITH CHECK表达式的行 都会导致错误，并且整个命令将被中止。如果只指定了一个 USING子句，那么该子句将被用于 USING和WITH CHECK两种情况。
通常，UPDATE命令还需要从待更新关系的列中读取 数据（例如在WHERE子句、 RETURNING子句，或SET 子句右侧的表达式中）。这种情况下，正在被更新的关系上也需要 SELECT权限，并且除了 UPDATE策略外，还会应用适当的 SELECT或ALL策略。这样， 用户除了必须通过UPDATE或 ALL策略获准更新这些行之外，还必须通过 SELECT或ALL策略访问 正在被更新的行。
当INSERT命令带有辅助ON CONFLICT DO UPDATE子句时，如果采用UPDATE路径，则首先根据任何UPDATE策略的USING表达式检查要更新的行，然后根据WITH CHECK表达式检查更新后的新行。但是请注意，与独立的UPDATE命令不同，如果现有行不通过USING表达式，则会抛出错误（UPDATE路径绝不会被静默跳过）。
DELETE #对策略使用DELETE意味着该策略适用于DELETE命令。DELETE命令只能看到通过该策略的行。如果某些行不通过DELETE策略的USING表达式，则它们可能通过SELECT可见，但不能被删除。
在多数情况下，DELETE命令也需要从其删除所针对 的关系中的列读取数据（例如在WHERE子句或 RETURNING子句中）。这种情况下，该关系上也 需要SELECT权限，并且除了 DELETE策略外，还会应用适当的 SELECT或ALL策略。这样， 用户除了必须通过DELETE或 ALL策略获准删除这些行之外，还必须通过 SELECT或ALL策略访问 正在被删除的行。
DELETE策略不能具有WITH CHECK表达式，因为它只适用于正在从关系中删除行的情况， 所以没有新行需要检查。
Table 272. 按命令类型应用的策略
| 命令 | SELECT/ALL policy |
INSERT/ALL policy |
UPDATE/ALL policy |
DELETE/ALL policy |
|
|---|---|---|---|---|---|
USING expression |
WITH CHECK expression |
USING expression |
WITH CHECK expression |
USING expression |
|
SELECT |
现有行 | — | — | — | — |
SELECT FOR UPDATE/SHARE |
现有行 | — | 现有行 | — | — |
INSERT |
— | 新行 | — | — | — |
INSERT ... RETURNING |
新行[a] | 新行 | — | — | — |
UPDATE |
现有 & 新行[a] | — | 现有行 | 新行 | — |
DELETE |
现有行[a] | — | — | — | 现有行 |
ON CONFLICT DO UPDATE |
现有 & 新行 | — | 现有行 | 新行 | — |
|
[a] 如果需要读取现有行或新行（例如引用关系中列的 |
|||||
当不同命令类型的多条策略应用于同一命令时（例如 SELECT和UPDATE策略应用于 UPDATE命令），用户必须同时具有这两种权限 （例如既有从该关系中选取行的权限，也有更新这些行的权限）。因此， 一种策略类型的表达式会与另一种策略类型的表达式使用 AND操作符组合。
当同一命令类型的多条策略应用于同一命令时，必须至少有一条 PERMISSIVE策略授予对该关系的访问权，并且所有 RESTRICTIVE策略都必须通过。因此，所有 PERMISSIVE策略表达式使用OR 组合，所有RESTRICTIVE策略表达式使用 AND组合，然后再将两者的结果使用 AND组合。如果没有 PERMISSIVE策略，则访问被拒绝。
请注意，就组合多条策略而言，ALL策略会被视为与 当前正在应用的其他策略同一类型。
例如，对于一个同时需要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 ... )
要为一个表创建或修改策略，你必须是该表的拥有者。
虽然策略会应用于针对数据库中表的显式查询，但当系统执行内部引用 完整性检查或验证约束时，并不会应用这些策略。这意味着仍然存在间接判断 某个给定值是否存在的方法。一个例子是，尝试向某个主键列或带有唯一约束 的列插入重复值。如果插入失败，用户就能推断该值已经存在。（这个例子 假定策略允许该用户插入自己无权看见的行。）另一个例子是，用户被允许 向一个引用了另一张表的表中插入数据，而被引用的那张表本身对其是隐藏 的。用户可以通过向引用表插入值来判断其存在性；插入成功就表示该值 存在于被引用表中。要解决这些问题，可以仔细设计策略，防止用户插入、 删除或更新那些可能暗示其本来无权看见的值是否存在的行，或者改用生成 的值（例如代理键）来代替具有外部含义的键。
通常，为了防止受保护的数据无意间暴露给可能不可信的用户定义函数， 系统会在应用用户查询中出现的条件之前，先强制执行安全策略施加的 过滤条件。不过，被系统（或系统管理员）标记为 LEAKPROOF的函数和操作符由于被假定为可信，可以在 策略表达式之前求值。
由于策略表达式会直接添加到用户的查询中，因此它们会以执行整个查询的用户权限运行。因此，使用给定策略的用户必须能够访问表达式中引用的任何表或函数，否则在尝试查询启用了行级安全性的表时，只会收到权限被拒绝错误。不过，这不会改变视图的工作方式。与普通查询和视图一样，视图所引用表的权限检查和策略会使用视图所有者的权限，以及适用于视图所有者的任何策略。
更多讨论和实际示例请参见Section 5.8。
CREATE POLICY是一种PostgreSQL扩展。