Hello,
I am using updateable views to have time-based tables (some status is
valid for some time and has to be preserved after updates, inserts and
deletes)
I created DO INSTEAD rules for update, insert and delete, example:
CREATE OR REPLACE RULE formularfeld_update AS
ON UPDATE TO formularfeld
DO INSTEAD ( UPDATE otformularfeld SET validbis = now(),
letztespeicherung = now()
WHERE otformularfeld.id_formfeld = old.id_formfeld AND
otformularfeld.validbis >= '9999-12-31 00:00:00'::timestamp without
time zone AND otformularfeld.quarant = get_quarant();
INSERT INTO otformularfeld (id_formfeld, id_formular, id_bf,
sortierung, ebene, gruppe, letztespeicherung, einblenden, ausblenden,
drucknr, untergruppe, validvon, validbis, id_user, quarant)
VALUES (new.id_formfeld, new.id_formular, new.id_bf, new.sortierung,
new.ebene, new.gruppe, now(), new.einblenden, new.ausblenden,
new.drucknr, new.untergruppe, now(), 'infinity'::timestamp without
time zone, get_user(), get_quarant());
);
(that is: write "this line is no longer valid", and "from now on this
line is valid instead")
Everything works fine. Just the feedbacks are ... disturbing:
update formularfeld set sortierung=1442 where id_formfeld=13798
leads to:
Query returned successfully: 0 rows affected, 234 ms execution time.
which is correct in one sence:
- within the updateable view there were 0 rows affected - all stuff
is done in otformularfeld; the table "behind the view"
on the other hand: the instead rule "touched" two rows in
otformularfeld. And this is reflected nowhere.
So my question: can I have influence on that query result message, and
if yes, how? My only option so far would be to have some function
"called" within the instead rule that raises "NOTICE" ... which seems
rather hackisch.
Harald
--
GHUM Harald Massa
persuadere et programmare
Harald Armin Massa
Spielberger Straße 49
70435 Stuttgart
0173/9409607
no fx, no carrier pigeon
-
EuroPython 2009 will take place in Birmingham - Stay tuned!