由于 PostgreSQL 规则系统对查询的重写， 非初始查询指定的其他表/视图被访问。 使用更新规则的时候，这可能包括对表的写权限。
重写规则并不拥有一个独立的所有者。 关系（表或视图）的所有者自动成为重写规则的缺省所有者。 PostgreSQL 规则系统改变缺省的访问控制系统的特性。 因规则而使用的关系在（规则）重写时要对定义规则所有者进行权限检查， 而不是激活规则的用户这意味着一个用户只需要对他的查询里明确指定的表/视图拥有所需的权限就可进行操作。
例如：某用户有一个电话号码列表，其中一些是私人的， 另外的一些是办公室秘书需要的。他可以用下面方法构建（查询）：
CREATE TABLE phone_data (person text, phone text, private boolean);
CREATE VIEW phone_number AS
SELECT person, phone FROM phone_data WHERE NOT private;
GRANT SELECT ON phone_number TO secretary;除了他以外（还有数据库超级用户）没有人可以访问 phone_data 表。 但因为GRANT，秘书可以从 phone_number 视图上运行SELECT。 规则系统将把从 phone_number 里的SELECT重写为从 phone_data 里的SELECT并将增加资格（条件）。 只有private条件为假的记录才可以选出。因为用户是 phone_number 的所有者， 因此也是规则的所有者，所以现在要检查他对 phone_data 的读访问的权限， 而这个查询是被允许的。同时也要检查访问 phone_number 的权限， 但这是对一个被撤消权限的用户进行检查的，所以除了用户自己和秘书外没有人可以使用它。
权限检查是按规则逐条进行的。 所以此时的秘书是唯一的一个可以看到公共电话号码的人。 但秘书可以设立另一个视图并且赋予该视图公共权限。 这样，任何人都可以通过秘书的视图看到 phone_number 数据。 秘书不能做的事情是创建一个直接访问 phone_data 的视图（实际上他是可以的，但没有任何作用， 因为每个访问都会因通不过权限检查而被踢出事务）。 而且用户很快会认识到，秘书开放了他的 phone_number 视图后， 他还可以REVOKE（撤回）他的访问权限。 这样，所有对秘书视图的访问马上就失效了。
有些人会认为这种逐条规则的检查是一个安全漏洞，但事实上不是。 如果这样做不能奏效， 秘书将必须建立一个与 phone_number 有相同字段的表并且每天一次的拷贝数据进去。 那么这是他自己的数据因而他可以赋予他允许的任何人访问的权力。 一个GRANT意味着 "我信任你"。如果某个你信任的人做了上面的事情， 那你就该想想是否该REVOKE了。
这个机制同样可以用于更新规则。在上一章的例子里， 例子数据库里的表的所有者可以把（赋予）shoelace视图 的权限 SELECT，INSERT，UPDATE 和 DELETE 赋予其它人。 但对 shoelace 只有 SELECT 权限。 写日志记录的规则动作（action）仍然可以成功的执行。 并且其它用户可以看到日志记录。但他不能创建伪记录， 而且他也不能对现有记录进行修改或删除。