AS YOU CAN SEE TWO ROWS WHERE UPDATED INSTEAD OF ONE !! THE COMMON THINGS BETWEEN THE TWO ROWS IS THAT THE FIELDS: cod_etu, cursus_id,vers_id,code_type_academic are the same
Because that's what you asked upd1/2 to do for you. To see what is happening, try selecting row id=53597 then manually running each rule yourself, substituting in the OLD.foo from your selected row. You should find that there are two rows that match 53597 on (cursus_id, vers_id, traiter, code_type_academic) - itself and one other.
Sorry, I didn't understand the manuel test procedure
What is happening here? I am doing an update and the condition is on the ID and it is corresponding to the last Rule so why should the other rules interfer.
ALL rules get executed. Conditions get combined (actually, parse trees get merged).
=== BEGIN rule_test.sql === CREATE TABLE foo (a int4 PRIMARY KEY, b text);
COPY foo FROM stdin; 1 aaa 2 bbb 3 ccc 4 aaa 5 bbb 6 ccc \.
CREATE VIEW foo_v AS SELECT * FROM foo WHERE b='bbb';
CREATE RULE foo_v_upd1 AS ON UPDATE TO foo_v DO INSTEAD UPDATE foo SET b = 'z' || NEW.b WHERE a = OLD.a;
SELECT * FROM foo ORDER BY a;
UPDATE foo_v SET b='xxx';
SELECT * FROM foo ORDER BY a; === END rule_test.sql ===
This will update 2 rows (those with b='bbb') since we impose no WHERE in our update but the view does. The OLD/NEW refer to target rows before/after the change.
Does that make things clearer? -- Richard Huxton Archonet Ltd
---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings
