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

shoelace_data.sl_name,　shoelace.sl_name);
同样这是一个　INSTEAD　规则并且前一个分析树被丢弃掉．注意这个查询仍然是使用视图　shoelace　，但是规则系统还没有完成（规则）循环，所以它继续对（分析树）应用规则　'_RETshoelace'，然后我们得到　
　　　　UPDATE　shoelace_data　SET
　　　　　　　　　　　sl_name　=　s.sl_name,
　　　　　　　　　　　sl_avail　=　int4pl(s.sl_avail,　shoelace_arrive.arr_quant),
　　　　　　　　　　　sl_color　=　s.sl_color,
　　　　　　　　　　　sl_len　=　s.sl_len,
　　　　　　　　　　　sl_unit　=　s.sl_unit
　　　　　　FROM　shoelace_arrive　shoelace_arrive,　shoelace_ok　shoelace_ok,
　　　　　　　　　　　shoelace_ok　*OLD*,　shoelace_ok　*NEW*,
　　　　　　　　　　　shoelace　shoelace,　shoelace　*OLD*,
　　　　　　　　　　　shoelace　*NEW*,　shoelace_data　showlace_data,
　　　　　　　　　　　shoelace　*OLD*,　shoelace　*NEW*,
　　　　　　　　　　　shoelace_data　s,　unit　u
　　　　　WHERE　bpchareq(s.sl_name,　showlace_arrive.arr_name)
　　　　　　　AND　bpchareq(shoelace_data.sl_name,　s.sl_name);
同样又是应用了一个更新规则并且我们继续规则的附加，到了重写的第三轮．这回应用规则　'log_shoelace'　生成下面分析树　
　　　　INSERT　INTO　shoelace_log　SELECT
　　　　　　　　　　　s.sl_name,
　　　　　　　　　　　int4pl(s.sl_avail,　shoelace_arrive.arr_quant),
　　　　　　　　　　　getpgusername(),
　　　　　　　　　　　datetime('now'::text)
　　　　　　FROM　shoelace_arrive　shoelace_arrive,　shoelace_ok　shoelace_ok,
　　　　　　　　　　　shoelace_ok　*OLD*,　shoelace_ok　*NEW*,
　　　　　　　　　　　shoelace　shoelace,　shoelace　*OLD*,
　　　　　　　　　　　shoelace　*NEW*,　shoelace_data　showlace_data,
　　　　　　　　　　　shoelace　*OLD*,　shoelace　*NEW*,
　　　　　　　　　　　shoelace_data　s,　unit　u,
　　　　　　　　　　　shoelace_data　*OLD*,　shoelace_data　*NEW*
　　　　　　　　　　　shoelace_log　shoelace_log
　　　　　WHERE　bpchareq(s.sl_name,　　showlace_arrive.arr_name)
　　　　　　　AND　bpchareq(shoelace_data.sl_name,　s.sl_name);
　　　　　　　AND　int4ne(int4pl(s.sl_avail,　shoelace_arrive.arr_quant),
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　s.sl_avail);
在所有的规则都应用完后返回生成的分析树．所以我们最终得到两个等效于下面　SQL　语句的分析树　
　　　　INSERT　INTO　shoelace_log　SELECT
　　　　　　　　　　　s.sl_name,
　　　　　　　　　　　s.sl_avail　+　shoelace_arrive.arr_quant,
　　　　　　　　　　　getpgusername(),
　　　　　　　　　　　'now'
　　　　　　FROM　shoelace_arrive　shoelace_arrive,　shoelace_data　shoelace_data,
　　　　　　　　　　　shoelace_data　s
　　　　　WHERE　s.sl_name　=　shoelace_arrive.arr_name
　　　　　　　AND　shoelace_data.sl_name　=　s.sl_name
　　　　　　　AND　s.sl_avail　+　shoelace_arrive.arr_quant　!=　s.sl_avail;
　　　　　　　　　　　
　　　　UPDATE　shoelace_data　SET
　　　　　　　　　　　sl_avail　=　shoelace_data.sl_avail　+　shoelace_arrive.arr_quant
　　　　　FROM　shoelace_arrive　shoelace_arrive,
　　　　　　　　　　shoelace_data　shoelace_data,
　　　　　　　　　　shoelace_data　s
　　　　WHERE　s.sl_name　=　shoelace_arrive.sl_name
　　　　　　AND　shoelace_data.sl_name　=　s.sl_name;
结果是从一个关系来的数据插入到另一个中，到了第三个中变成更新，在到第四个中变成更新加上记日志，最后在第五个规则中缩减为两个查询．　
有一个小细节有点让人难受．看看生成的查询，shoelace_data　关系在可排列元素中出现了两次而实际上绝对可以缩为一次．因为优化器不处理这些，所以对规则系统输出的　INSERT　的执行规划会是　

Nested　Loop
　　->　　Merge　Join
　　　　　　　　->　　Seq　Scan
　　　　　　　　　　　　　　->　　Sort
　　　　　　　　　　　　　　　　　　　　->　　Seq　Scan　on　s
　　　　　　　　->　　Seq　Scan
　　　　　　　　　　　　　　->　　Sort
　　　　　　　　　　　　　　　　　　　　->　　Seq　Scan　on　shoelace_arrive
　　->　　Seq　Scan　on　shoelace_data
在省略多余的可排列元素后的结果将是　
Merge　Join
　　->　　Seq　Scan
　　　　　　　　->　　Sort
　　　　　　　　　　　　　　->　　Seq　Scan　on　s
　　->　　Seq　Scan
　　　　　　　　->　　Sort
　　　　　　　　　　　　　　->　　Seq　Scan　on　shoelace_arrive
这也会在日志关系中生成完全一样的记录．因此，规则系统导致对　shoelace_data　关系的一次多余的扫描，而且同样多余的扫描会在　UPDATE　里也一样多做一次．不过要想把这些不足去掉是一样太困难的活了．　
Postgres　规则系统及其功能的最后一个演示．有个金发美女出售鞋带．而且　Al　可能永远不知道的是，她不仅漂亮，而且聪明　－有点太聪明了．因此，时不时的会发生　Al　订购的鞋带完全不能销售的情况．这回他定了1000对洋红色的鞋带并且因为其他类型的目前还没货所以他忘了买一些，他还准备在他的数据库里增加一些粉红的鞋带．　

　　　　al_bundy=>　INSERT　INTO　shoelace　VALUES　
　　　　al_bundy->　　　　　('sl9',　0,　'pink',　35.0,　'inch',　0.0);
　　　　al_bundy=>　INSERT　INTO　shoelace　VALUES　
　　　　al_bundy->　　　　　('sl10',　1000,　'magenta',　40.0,　'inch',　0.0);
因为常发生这种事，我们必须看一眼鞋带记录表，看看有没有那些某一时段没有相配的鞋子的（鞋带）．我们可以在每次都用一个复杂的语句实现这些，或者我