Hi all,
I've been using RULES for some time now, and despite the fact, that I
always had to make "experiments" to have the expected results, it worked
for me just fine.
Now I have this simple scenario:
---------------------------------------------------
mbr2=# CREATE TEMP TABLE test(a int, b date);
CREATE TABLE
mbr2=# INSERT INTO test (a) values (22);
INSERT 0 1
mbr2=# CREATE TEMP VIEW testing AS SELECT * from test;
CREATE VIEW
mbr2=# SELECT * from testing;
a | b
----+---
22 |
(1 row)
mbr2=# CREATE RULE chg_testing_1 AS ON UPDATE TO testing where new.b is
not null do instead select '+++';
CREATE RULE
mbr2=# CREATE RULE chg_testing_2 AS ON UPDATE TO testing do instead
select '===';
CREATE RULE
mbr2=# UPDATE testing set a=44;
?column?
----------
===
(1 row)
UPDATE 0
mbr2=# UPDATE testing set a=44, b=current_date;
?column?
----------
===
(1 row)
UPDATE 0
mbr2=#
------------------------------------------
And I'm completely lost how to interpret the outcome:
1. I know, that RULEs countrary to TRIGGERs "rewrite" query, resulting
in actual execution of a different query from originally scheduled
2. while triggers "take" rows of processed data "and do their job
there".
Now, the above example does not behave as I would expect.
I really don't understand why both of the above updates give the same
result here and it boils down to: how come a RULE can have a look at
"NEW.B", if it's supposed to be rewritten *before* any rows are fetched
for processing? When exactly does it "have a look" at the NEW.B? How do
I ensure, that the "DO INSTEAD NOTHING" rule *does*not* get executted
when a conditional rule does?
Can someone give a little explenation here ... or point me to "for
dummies" documentation? (yes, I've been though postgres docs, to no
avail).
I'll apreciate that, really.
-R
