除了通过 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。