I find the following behavior confusing:
neilc=# create table t1 (a int, b int);
CREATE TABLE
neilc=# create table t2 (a int, b int);
CREATE TABLE
neilc=# create table t3 (a int, b int);
CREATE TABLE
neilc=# create rule t1_rule1 as on insert to t1 where NEW.a > 100 do
instead insert into t2 values (NEW.a, NEW.b);
CREATE RULE
neilc=# create rule t1_rule2 as on insert to t1 do instead insert into
t3 values (NEW.a, NEW.b);
CREATE RULE
neilc=# insert into t1 values (200, 400);
INSERT 0 1
neilc=# select * from t2; a | b
-----+----- 200 | 400
(1 row)
neilc=# select * from t3; a | b
-----+----- 200 | 400
Note that although both rules are DO INSTEAD, they both get fired for
the insertion. I would have expected that we would iterate through the
rules in alphabetical order, firing rules whose conditionals match, and
stopping when we run out of parsetrees (e.g. after applying a DO INSTEAD
rule). In this case, that would mean only inserting into t2. (The above
example behaves the same if we substitute "DO ALSO" for "DO INSTEAD" in
the definition of t1_rule1.)
The rule documentation does suggest this, albeit in a very confusing manner:
****
So we have four cases that produce the following query trees for a
one-action rule.
[...]
Qualification given and INSTEAD
the query tree from the rule action with the rule qualification and
the original query tree's qualification; and the original query tree
with the negated rule qualification added
****
Can anyone explain why the system behaves like this?
-Neil
