除了通过 权限系统 (GRANT) 提供的 SQL 标准权限系统之外，表还可以具有 行级安全策略，这些策略可以基于每个用户限制正常查询可以返回哪些行，或者数据修改命令可以插入、更新或删除哪些行。此功能也称为 行级安全。默认情况下，表没有任何策略，因此，如果用户根据 SQL 权限系统具有表访问权限，则表中的所有行对于查询或更新都是同等可用的。

当在表上启用行级安全（使用 ALTER TABLE ... ENABLE ROW LEVEL SECURITY）时，所有对表的正常访问（用于选择行或修改行）都必须由行级安全策略允许。（但是，表的所有者通常不受行级安全策略的约束。）如果表不存在任何策略，则使用默认拒绝策略，这意味着任何行都不可见或无法修改。应用于整个表的运算（如 TRUNCATE 和 REFERENCES）不受行级安全的约束。

行级安全策略可以特定于命令、角色或两者兼而有之。可以指定策略应用于 ALL 命令，或应用于 SELECT、INSERT、UPDATE 或 DELETE。可以将多个角色分配给给定策略，并且适用正常的角色成员资格和继承规则。

要指定哪些行根据策略可见或可修改，需要一个表达式，该表达式返回布尔结果。此表达式将在任何来自用户查询的条件或函数之前针对每一行进行评估。（此规则的唯一例外是 leakproof 函数，这些函数保证不会泄漏信息；优化器可以选择在行安全检查之前应用此类函数。）表达式不返回 true 的行将不会被处理。可以指定单独的表达式来独立控制可见的行和允许修改的行。策略表达式作为查询的一部分运行，并使用运行查询的用户权限运行，尽管安全定义者函数可用于访问调用用户无法访问的数据。

超级用户和具有 BYPASSRLS 属性的角色在访问表时始终绕过行安全系统。表所有者通常也会绕过行安全，尽管表所有者可以选择通过 ALTER TABLE ... FORCE ROW LEVEL SECURITY 接受行安全。

启用和禁用行级安全以及向表添加策略始终只有表所有者才有权。

策略使用 CREATE POLICY 命令创建，使用 ALTER POLICY 命令修改，并使用 DROP POLICY 命令删除。要启用和禁用给定表的行级安全，请使用 ALTER TABLE 命令。

每个策略都有一个名称，并且可以为一个表定义多个策略。由于策略是特定于表的，因此表中的每个策略都必须具有唯一的名称。不同的表可以具有相同名称的策略。

当多个策略应用于给定查询时，它们使用 OR（对于宽松策略，这是默认值）或 AND（对于严格策略）组合。这类似于给定角色具有其所有成员角色的权限的规则。宽松策略与严格策略将在下面进一步讨论。

作为一个简单的示例，以下是如何在 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);

上面的策略隐式提供了一个与 USING 子句相同的 WITH CHECK 子句，以便约束同时应用于命令选择的行（因此管理器无法 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);

在 SELECT 命令中，这两个策略使用 OR 组合，其净效果是所有行都可以被选择。在其他命令类型中，仅应用第二个策略，因此效果与之前相同。

行级安全也可以使用 ALTER TABLE 命令禁用。禁用行级安全不会删除在表上定义的任何策略；它们只是被忽略。然后，表中的所有行都是可见的和可修改的，受标准 SQL 权限系统的约束。

下面是此功能如何在生产环境中使用的较大的示例。表 passwd 模拟 Unix 密码文件

-- Simple passwd-file based example
CREATE TABLE passwd (
  user_name             text UNIQUE NOT NULL,
  pwhash                text,
  uid                   int  PRIMARY KEY,
  gid                   int  NOT NULL,
  real_name             text NOT NULL,
  home_phone            text,
  extra_info            text,
  home_dir              text NOT NULL,
  shell                 text NOT NULL
);

CREATE ROLE admin;  -- Administrator
CREATE ROLE bob;    -- Normal user
CREATE ROLE alice;  -- Normal user

-- Populate the table
INSERT INTO passwd VALUES
  ('admin','xxx',0,0,'Admin','111-222-3333',null,'/root','/bin/dash');
INSERT INTO passwd VALUES
  ('bob','xxx',1,1,'Bob','123-456-7890',null,'/home/bob','/bin/zsh');
INSERT INTO passwd VALUES
  ('alice','xxx',2,1,'Alice','098-765-4321',null,'/home/alice','/bin/zsh');

-- Be sure to enable row-level security on the table
ALTER TABLE passwd ENABLE ROW LEVEL SECURITY;

-- Create policies
-- Administrator can see all rows and add any rows
CREATE POLICY admin_all ON passwd TO admin USING (true) WITH CHECK (true);
-- Normal users can view all rows
CREATE POLICY all_view ON passwd FOR SELECT USING (true);
-- Normal users can update their own records, but
-- limit which shells a normal user is allowed to set
CREATE POLICY user_mod ON passwd FOR UPDATE
  USING (current_user = user_name)
  WITH CHECK (
    current_user = user_name AND
    shell IN ('/bin/bash','/bin/sh','/bin/dash','/bin/zsh','/bin/tcsh')
  );

-- Allow admin all normal rights
GRANT SELECT, INSERT, UPDATE, DELETE ON passwd TO admin;
-- Users only get select access on public columns
GRANT SELECT
  (user_name, uid, gid, real_name, home_phone, extra_info, home_dir, shell)
  ON passwd TO public;
-- Allow users to update certain columns
GRANT UPDATE
  (pwhash, real_name, home_phone, extra_info, shell)
  ON passwd TO public;

与任何安全设置一样，重要的是要进行测试并确保系统按预期运行。使用上面的示例，这证明了权限系统正在正常工作。

-- admin can view all rows and fields
postgres=> set role admin;
SET
postgres=> table passwd;
 user_name | pwhash | uid | gid | real_name |  home_phone  | extra_info | home_dir    |   shell
-----------+--------+-----+-----+-----------+--------------+------------+-------------+-----------
 admin     | xxx    |   0 |   0 | Admin     | 111-222-3333 |            | /root       | /bin/dash
 bob       | xxx    |   1 |   1 | Bob       | 123-456-7890 |            | /home/bob   | /bin/zsh
 alice     | xxx    |   2 |   1 | Alice     | 098-765-4321 |            | /home/alice | /bin/zsh
(3 rows)

-- Test what Alice is able to do
postgres=> set role alice;
SET
postgres=> table passwd;
ERROR:  permission denied for table passwd
postgres=> select user_name,real_name,home_phone,extra_info,home_dir,shell from passwd;
 user_name | real_name |  home_phone  | extra_info | home_dir    |   shell
-----------+-----------+--------------+------------+-------------+-----------
 admin     | Admin     | 111-222-3333 |            | /root       | /bin/dash
 bob       | Bob       | 123-456-7890 |            | /home/bob   | /bin/zsh
 alice     | Alice     | 098-765-4321 |            | /home/alice | /bin/zsh
(3 rows)

postgres=> update passwd set user_name = 'joe';
ERROR:  permission denied for table passwd
-- Alice is allowed to change her own real_name, but no others
postgres=> update passwd set real_name = 'Alice Doe';
UPDATE 1
postgres=> update passwd set real_name = 'John Doe' where user_name = 'admin';
UPDATE 0
postgres=> update passwd set shell = '/bin/xx';
ERROR:  new row violates WITH CHECK OPTION for "passwd"
postgres=> delete from passwd;
ERROR:  permission denied for table passwd
postgres=> insert into passwd (user_name) values ('xxx');
ERROR:  permission denied for table passwd
-- Alice can change her own password; RLS silently prevents updating other rows
postgres=> update passwd set pwhash = 'abc';
UPDATE 1

迄今为止构建的所有策略都是宽松策略，这意味着当应用多个策略时，它们使用布尔运算符 “OR” 组合。虽然可以构建宽松策略以仅允许访问预期情况下的行，但将宽松策略与严格策略（记录必须通过且使用布尔运算符 “AND” 组合）组合可能更简单。基于上面的示例，我们添加一个严格策略，要求管理员通过本地 Unix 套接字连接才能访问 passwd 表的记录

CREATE POLICY admin_local_only ON passwd AS RESTRICTIVE TO admin
    USING (pg_catalog.inet_client_addr() IS NULL);

然后我们可以看到，由于严格策略，通过网络连接的管理员将看不到任何记录

=> SELECT current_user;
 current_user
--------------
 admin
(1 row)

=> select inet_client_addr();
 inet_client_addr
------------------
 127.0.0.1
(1 row)

=> TABLE passwd;
 user_name | pwhash | uid | gid | real_name | home_phone | extra_info | home_dir | shell
-----------+--------+-----+-----+-----------+------------+------------+----------+-------
(0 rows)

=> UPDATE passwd set pwhash = NULL;
UPDATE 0

引用完整性检查（例如唯一或主键约束以及外键引用）始终绕过行级安全以确保维护数据完整性。在开发模式和行级策略时必须注意避免通过此类引用完整性检查 “隐蔽信道” 泄漏信息。

在某些情况下，务必确保未应用行级安全。例如，在进行备份时，如果行级安全静默地导致某些行从备份中省略，则可能是灾难性的。在这种情况下，您可以将 row_security 配置参数设置为 off。这本身不会绕过行安全；它所做的是在任何查询的结果将被策略过滤时引发错误。然后可以调查和修复错误的原因。

在上面的示例中，策略表达式仅考虑要访问或更新的行中的当前值。这是最简单且性能最好的情况；如果可能，最好设计行安全应用程序以这种方式工作。如果需要查询其他行或其他表才能做出策略决策，则可以通过在策略表达式中使用子 SELECT 或包含 SELECT 的函数来实现。但是请注意，如果不小心，此类访问可能会创建可能允许信息泄漏的竞争条件。例如，考虑以下表设计

-- definition of privilege groups
CREATE TABLE groups (group_id int PRIMARY KEY,
                     group_name text NOT NULL);

INSERT INTO groups VALUES
  (1, 'low'),
  (2, 'medium'),
  (5, 'high');

GRANT ALL ON groups TO alice;  -- alice is the administrator
GRANT SELECT ON groups TO public;

-- definition of users' privilege levels
CREATE TABLE users (user_name text PRIMARY KEY,
                    group_id int NOT NULL REFERENCES groups);

INSERT INTO users VALUES
  ('alice', 5),
  ('bob', 2),
  ('mallory', 2);

GRANT ALL ON users TO alice;
GRANT SELECT ON users TO public;

-- table holding the information to be protected
CREATE TABLE information (info text,
                          group_id int NOT NULL REFERENCES groups);

INSERT INTO information VALUES
  ('barely secret', 1),
  ('slightly secret', 2),
  ('very secret', 5);

ALTER TABLE information ENABLE ROW LEVEL SECURITY;

-- a row should be visible to/updatable by users whose security group_id is
-- greater than or equal to the row's group_id
CREATE POLICY fp_s ON information FOR SELECT
  USING (group_id <= (SELECT group_id FROM users WHERE user_name = current_user));
CREATE POLICY fp_u ON information FOR UPDATE
  USING (group_id <= (SELECT group_id FROM users WHERE user_name = current_user));

-- we rely only on RLS to protect the information table
GRANT ALL ON information TO public;

现在假设 alice 希望更改 “稍微秘密的” 信息，但认为 mallory 不应该被信任查看该行的新的内容，因此她执行以下操作

BEGIN;
UPDATE users SET group_id = 1 WHERE user_name = 'mallory';
UPDATE information SET info = 'secret from mallory' WHERE group_id = 2;
COMMIT;

这看起来很安全；没有窗口允许 mallory 看到 “来自 mallory 的秘密” 字符串。但是，这里存在竞争条件。如果 mallory 同时执行以下操作，例如，

SELECT * FROM information WHERE group_id = 2 FOR UPDATE;

并且她的事务处于 READ COMMITTED 模式，她可能能够看到 “来自 mallory 的秘密”。如果她的事务在 alice 的事务之后到达 information 行，就会发生这种情况。它会阻塞，等待 alice 的事务提交，然后由于 FOR UPDATE 子句而获取更新的行内容。但是，它 不会 获取来自 users 的隐式 SELECT 的更新行，因为该子 SELECT 没有 FOR UPDATE；而是使用查询开始时拍摄的快照读取 users 行。因此，策略表达式测试 mallory 权限级别的旧值，并允许她查看更新的行。

解决这个问题有几种方法。一个简单的答案是在行安全策略的子SELECT中使用SELECT ... FOR SHARE。但是，这需要授予受影响用户对引用表（此处为users）的UPDATE权限，这可能是不希望的。（但是，可以应用另一个行安全策略来阻止他们实际行使该权限；或者可以将子SELECT嵌入到安全定义器函数中。）此外，在引用表上大量并发使用行共享锁可能会导致性能问题，尤其是在该表更新频繁的情况下。另一种解决方案，如果引用表的更新不频繁，则可以实际操作，即在更新引用表时获取该表的ACCESS EXCLUSIVE锁，以便没有并发事务可以检查旧的行值。或者，可以在提交引用表的更新后，并在进行依赖于新安全状况的更改之前，等待所有并发事务结束。

有关更多详细信息，请参见CREATE POLICY和ALTER TABLE。