PGsql学习笔记:行安全性策略

1、当在一个表上启用行安全性时：

使用 ALTER TABLE ... ENABLE ROW LEVEL SECURITY

2、具有BYPASSRLS属性的超级用户和角色在访问一个表时总是 可以绕过行安全性系统。表拥有者通常也能绕过行安全性，表的拥有者通常不服从行安全性策略。
不过表拥有者 可以选择用

ALTER TABLE ... FORCE ROW LEVEL SECURITY

来服从行安全性。
启用和禁用行安全性以及向表增加策略是只有表拥有者具有的特权。

3、策略的创建可以使用CREATE POLICY命令，
策略的修改 可以使用ALTER POLICY命令，
而策略的删除可以使用 DROP POLICY命令。
要为一个给定表启用或者禁用行 安全性，可以使用ALTER TABLE命令。

4、每一条策略都有名称并且可以为一个表定义多条策略。由于策略是表相 关的，一个表的每一条策略都必须有一个唯一的名称。不同的表可以拥有 相同名称的策略。

作为一个简单的例子，这里是如何在account关系上 创建一条策略以允许只有managers角色的成员能访问行， 并且只能访问它们账户的行：

CREATE TABLE accounts (manager text, company text, contact_email text);
ALTER TABLE accounts ENABLE ROW LEVEL SECURITY;
CREATE POLICY account_managers ON accounts TO managers
    USING (manager = current_user);

上面的策略隐含地提供了一个与其该约束适用于被一个命令选择的行（这样一个经理不能SELECT、UPDATE或者DELETE属于其他经理的已有行）以及被一个命令修改的行（这样属于其他经理的行不能通过INSERT或者UPDATE创建）。

如果没有指定角色或者使用了特殊的用户名PUBLIC， 则该策略适用于系统上所有的用户。要允许所有用户访问users 表中属于他们自己的行，可以使用一条简单的策略：

CREATE POLICY user_policy ON users
    USING (user_name = current_user);

为了对增加到表中的行使用与可见行不同的策略，可以组合多条策略。这一对策略将允许所有用户查看users表中的所有行，但只能修改他们自己的行：

CREATE POLICY user_sel_policy ON users
    FOR SELECT
    USING (true);
CREATE POLICY user_mod_policy ON users
    USING (user_name = current_user);