Hallo Andreas
habe Deinen Hinweis wie folgt ausprobiert:
Zwei Tabellen:
CREATE TABLE tabelle
(
id serial NOT NULL, – ID, Primärschlüssel
wert varchar(20),
t_stamp timestamp,
CONSTRAINT tabelle_pkey PRIMARY KEY (id)
)
CREATE TABLE tabelle_hist
(
id int4 NOT NULL,
wert varchar(20),
t_stamp timestamp
)
eine Funktion:
CREATE OR REPLACE FUNCTION table_function_histo()
RETURNS “trigger” AS
$BODY$
BEGIN
INSERT INTO tabelle_hist (id, wert, t_stamp)
VALUES (OLD.id, OLD.wert, OLD.t_stamp);
UPDATE tabelle
SET t_stamp = ‘now’
where OLD.id = id;
RETURN new;
END;
$BODY$
LANGUAGE ‘plpgsql’ VOLATILE;
ALTER FUNCTION table_function_histo() OWNER TO postgres;
… und natürlich den TRIGGER:
CREATE TRIGGER trigger_upd
AFTER UPDATE
ON tabelle
FOR EACH ROW
EXECUTE PROCEDURE table_function_histo();
Sobald ich jedoch einen ‘wert’ in der Tabelle ‘tabelle’ ändere resultiert daraus eine endlose Rekursion.
Ginge es um meine Datenbank, würde ich die Timestamps zum protokollieren in eine extra Tabelle auslagern … hätte ja auch noch andere Vorteile.
Der Sinn des UPDATES von dem Timestamp bei jeder Änderung in der Originaltabelle (im Bsp. also ‘tabelle’) ist die Berücksichtigung bei umfangreichen Matching-Läufen der Datenbank.
Unter Informix kann man den Wert im Trigger direkt mittels ‘INTO’ in der betreffenden Tabelle ändern z.B. so:
…
FOR EACH ROW
EXECUTE PROCEDURE getTimestamp() INTO NEW.t_stamp;
wobei getTimestamp() einfach einen aktuellen Timestamp zurückliefert.
Kann man ggf. den TRIGGER so einrichten, das sich das UPDATE nur auf die Pseudo-Relation ‘NEW’ bezieht ?!
Viele Grüße,
Andreas