PostgreSQL7.0手册-程序员手册 -42. Postgres 规则系统

们可以创建一个用于这个方面的视图．如下　
　　　　CREATE　VIEW　shoelace_obsolete　AS
　　　　　　　　SELECT　*　FROM　shoelace　WHERE　NOT　EXISTS
　　　　　　　　　　　　(SELECT　shoename　FROM　shoe　WHERE　slcolor　=　sl_color);
它的输出是　
　　　　al_bundy=>　SELECT　*　FROM　shoelace_obsolete;
　　　　sl_name　　　|sl_avail|sl_color　　|sl_len|sl_unit　|sl_len_cm
　　　　----------+--------+----------+------+--------+---------
　　　　sl9　　　　　　　|　　　　　　　0|pink　　　　　　|　　　　35|inch　　　　|　　　　　88.9
　　　　sl10　　　　　　|　　　　1000|magenta　　　|　　　　40|inch　　　　|　　　　101.6
那　1000　条洋红色鞋带，在把它们仍掉之前我们必须先欠着　Al，不过那是另一回事．粉红的记录我们要删掉．为了让这事对　Postgres　有点难度，我们不直接删除它们．取而代之的是我们再创建一个视图　
　　　　CREATE　VIEW　shoelace_candelete　AS
　　　　　　　　SELECT　*　FROM　shoelace_obsolete　WHERE　sl_avail　=　0;
然后用下面方法做：　
　　　　DELETE　FROM　shoelace　WHERE　EXISTS
　　　　　　　　(SELECT　*　FROM　shoelace_candelete
　　　　　　　　　　　　　　　　　WHERE　sl_name　=　shoelace.sl_name);
所以：　
　　　　al_bundy=>　SELECT　*　FROM　shoelace;
　　　　sl_name　　　|sl_avail|sl_color　　|sl_len|sl_unit　|sl_len_cm
　　　　----------+--------+----------+------+--------+---------
　　　　sl1　　　　　　　|　　　　　　　5|black　　　　　|　　　　80|cm　　　　　　|　　　　　　　80
　　　　sl2　　　　　　　|　　　　　　　6|black　　　　　|　　　100|cm　　　　　　|　　　　　　100
　　　　sl7　　　　　　　|　　　　　　　6|brown　　　　　|　　　　60|cm　　　　　　|　　　　　　　60
　　　　sl4　　　　　　　|　　　　　　　8|black　　　　　|　　　　40|inch　　　　|　　　　101.6
　　　　sl3　　　　　　　|　　　　　　10|black　　　　　|　　　　35|inch　　　　|　　　　　88.9
　　　　sl8　　　　　　　|　　　　　　21|brown　　　　　|　　　　40|inch　　　　|　　　　101.6
　　　　sl10　　　　　　|　　　　1000|magenta　　　|　　　　40|inch　　　　|　　　　101.6
　　　　sl5　　　　　　　|　　　　　　　4|brown　　　　　|　　　　　1|m　　　　　　　|　　　　　　100
　　　　sl6　　　　　　　|　　　　　　20|brown　　　　　|　　　0.9|m　　　　　　　|　　　　　　　90
　　　　(9　rows)
对一个视图的　DELETE，这个视图带有一个总共使用了四个独立/联合的视图的子查询资格（条件），这四个视图之一本身有一个拥有对一个视图的子查询资格（条件），该条件计算使用的视图的列；最后重写成了一个分析树，该分析树从一个真正的表里面把需要删除的数据删除．　
我想在现实世界里只有很少的机会需要做上面的这类事情．但这些东西能工作让我很开心．　

真相是：我在写本文档时做上面的试验又发现了一个错误（bug）．但在去除该错误之后我有点惊奇的发现这些都正常工作了．

--------------------------------------------------------------------------------
--------------------------------------------------------------------------------

规则和权限
由于　Postgres　规则系统对查询的重写，非初始查询指定的其他表/视图被访问．使用更新规则，这可能包括对表的写权限．　
重写规则并不拥有一个独立的所有者．关系（表或视图）的所有者自动成为重写规则的缺省所有者．Postgres　规则系统改变缺省的访问控制系统的特性．因规则而使用的关系在（规则）重写时要对定义规则的关系所有者的权限进行检查．这意味着一个用户只需要对他的查询里指定的表/视图拥有所需的权限就可进行操作．　

例如：某用户有一个电话号码列表，其中一些是私人的，另外的一些是办公室秘书需要的．他可以用下面方法构建（查询）：　

　　　　CREATE　TABLE　phone_data　(person　text,　phone　text,　private　bool);
　　　　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　并将增加资格（条件）．只有私人条件为假的记录才可以选出．因为用户是　phone_number　的所有者，他对　phone_data　的读访问的权限现在要进行检查，而这个查询是被赋予的．所以对访问　phone_number　的权限检查仍然要进行，所以除了秘书外没有人可以使用它．　
权限检查是按规则逐条进行的．所以此时的秘书是唯一的一个可以看到公共电话号码的人．但秘书可以设立另一个视图并且赋予该视图公共权限．这样，任何人都可以通过秘书的视图看到　phone_number　数据．秘书不能做的事情是创建一个直接访问　phone_data　的视图（实际上他是可以的，但没有任何作用，因为每个访问都会因通不过权限检查而被踢出事务）．而且用户很快会认识到，秘书开放了他的　phone_number　视图后，他还可以　REVOKE　（撤回）他的访问权限．这样，所有对秘书视图的访问马上就失效了．　

有些人会认为这种逐条规则的检查是一个安全漏洞，但事实上不是．如果这样做不能奏效，秘书将必须建立一个与　phone_number　有相同字段的表并且每天一次的拷贝数据进去．那么这是他自己的数据因而他可以赋予他允许的任何人访问的权力．一个　GRANT　意味着　"我信任你"．如果某个你信任的人做了上面的事情，那你就该想想是否该　REVOKE　了．　

这个机制同样可以用于更新规则．在上一章的例子里，Al　的数据库里的表的所有者可以把（赋予）鞋带视图　GRANT　SELECT，INSERT，UPDATE　和　DELETE　给　al．但对　shoelace