PostgreSQL在9.5版本中，新增了特性(RLS)，该特性在数据安全体系提供了在传统的授权安全体系之外更细粒度的控制。对应的，Oracle在很久之前提供了类似的技术，该技术在Oracle10g时代就已经成熟。在SQL Server 2016中，也提供了类似的行级安全特性。如今PostgreSQL在本次发布的大版本中也提供了该新特性，本文将对该技术做详细地介绍，然后提出对应的应用级解决方案。
PostgreSQL 9.5 发布下载，带来 UPSERT 等新特性
1.行级安全性策略 1.1.行级安全策略概述在之前版本的数据安全技术中，是通过GRANT/REVOKE指令实现的，这两个指令提供了对象级的安全限制，针对表，还提供了列级的安全限制。但是很多场景中，往往希望不同的用户访问同一个表能看到不同的数据，也就是行级安全的需求，这个特性在9.5中提供了支持。该版本中，在正常的SQL查询和数据更新之外，可以附加额外的行级安全策略，可以限制查询返回以及数据操作的结果。默认的话，表没有任何安全策略限制。
所有对数据的操作，包括数据查询和数据更新，都受到策略的限制，如果没有配置安全策略，所有的数据查询和更新都会禁止，但是对全表进行操作的命令，比如TRUNCATE和REFERENCES不受影响。
行级安全策略可以加在命令上，也可以加在角色上，也可以两者都加。命令可以是ALL, SELECT, INSERT, UPDATE和DELETE,同一个策略也可以赋予多个角色。但是表的所有者，超级用户(postgres)以及加上了BYPASSRLS属性的角色不受安全性的限制。如果应用想忽略行级安全性机制的限制，也可以将设置为off。
启用行级安全的表如何对数据的查询和更新进行控制呢？这是通过一个返回布尔值的表达式实现的。这个表达式优先于查询条件和查询内的函数，这个规则唯一的例外是leakproof函数。这里需要两个表达式，分别对数据的查询和更新进行独立地控制。
只有所有者才具有启用/禁用行级安全性，给表添加策略的权限。
CREATE POLICY，ALTER POLICY，DROP POLICY命令分别用于策略的创建、修改和删除，ALTER TABLE可以用于行级安全性的启用/禁用。
每个策略都有一个名字，每个表可以定义多个策略，因为策略是针对表的，所以表内的多个策略名字必须唯一，但是不同的表可以有同名的策略，当表有多个策略时，多个策略之间是OR的关系。
1.2.相关示例 启用行级安全性要开启表的行级安全性，需要使用ALTER TABLE命令，如下：
CREATE TABLE user (id text, name text, email text,manager text); ALTER TABLE user ENABLE ROW LEVEL SECURITY;ALTER TABLE也可以用于禁用行级安全性，但是禁用之后并不删除相应的策略。
创建策略如果希望只有管理者才能看到对应的用户：
CREATE POLICY user_manager ON user TO managers USING (manager = current_user);如果未指定角色，那么默认为PUBLIC，即针对系统内的所有角色，如果希望系统内每个用户只能看到自己的数据，只需要创建一个下面的简单策略即可：
CREATE POLICY user_policy ON users USING (id = current_user);如果要限制对数据的更新操作，可以添加WITH CHECK语句，下面的策略允许所有人看到所有的数据，但是只能修改自己的数据：
CREATE POLICY user_policy ON user USING (true) WITH CHECK (id = current_user);关于创建策略的更详细的说明，可以参照CREATE POLICY命令的手册。
2.应用级解决方案从上述可以看出，PostgreSQL的行级安全性是针对登录到数据库的各个具有不同权限的用户的，这对于数据库的设计者来说没有问题，因为他们工作于数据库层。而在实际场景中我们是工作于应用层的，我们希望对应用中的同一条SQL语句，能进行不同的权限控制，这里面就涉及三个问题：
应用是通过一个共享的账户登录数据库的。
应用的规则可能很复杂。
还有一个就是可能需要很多的动态参数。
下面就针对上述三个问题，拿出应用级的解决方案。
2.1.三级账户体系在现实中，应用的开发为了方便，通常的做法是，先用超级用户(postgres)创建一个登录用户角色，然后用新创建的登录用户角色登录，再创建和登录用户名同名的数据库，然后应用也会用这个登录用户连接数据库。