PostgreSQL "Trigger" [erledigt]

Alles zum SQL-Dialekt

Moderator: Moderatoren

Antworten
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

PostgreSQL "Trigger" [erledigt]

Beitrag von AUGE_OHR »

hi,

wie bekomme ich einen "Trigger" angelegt ? ich meine das
Trigger.PNG
Trigger.PNG (32.38 KiB) 15619 mal betrachtet
ich habe nun "gelesen"
Pg Handbuch, S. 657 von 960

CREATE CONSTRAINT TRIGGER – definiert einen neuen Constraint-Trigger

Synopsis

Code: Alles auswählen

CREATE CONSTRAINT TRIGGER name
AFTER ereignisse ON
tabelle constraint attribute
FOR EACH ROW EXECUTE PROCEDURE funktion( argumente )
Beschreibung

Der Befehl CREATE CONSTRAINT TRIGGER wird in CREATE TABLE/ALTER TABLE und von pg_dump
verwendet, um die speziellen Trigger für referenzielle Integrität zu erzeugen. Er ist nicht für allgemeine Verwendung gedacht.
was der String für eine "Text" haben muss "sehe" ich ja, aber mir ist nicht klar wie ich den "einsetzte". "wo"/"wann" schicke ich den String ab ?

p.s. was bedeutet "CONSTRAINT" ? ich finde zwar massiv Treffer im Handbuch aber es ist mir immer noch nicht klar was das ist
... so was wie ein "Alias" ? oder o:cargo ? oder MemVar als Macro ?
Zuletzt geändert von AUGE_OHR am Fr, 27. Jul 2012 6:04, insgesamt 1-mal geändert.
gruss by OHR
Jimmy
georg
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2823
Registriert: Fr, 08. Feb 2008 21:29
Hat sich bedankt: 95 Mal
Danksagung erhalten: 13 Mal

Re: PostgreSQL "Trigger"

Beitrag von georg »

Hallo, Jimmy -


constraint bedeuet soviel wie

Bedingung
Auflage
(technische) Begrenzung

Das bedeutet im Klartext, dass ein constraint eine Bedigung definiert, die erfüllt sein muss, ehe eine Anforderung an die Tabelle(n) ausgeführt werden kann.

Ein primary key z.B. ist ein constraint, d.h. es wird nur dann ein neuer Satz angelegt, wenn es keinen anderen Satz gibt, der den gleichen (primary) key besitzt.

Zu Deiner Frage:
was der String für eine "Text" haben muss "sehe" ich ja, aber mir ist nicht klar wie ich den "einsetzte". "wo"/"wann" schicke ich den String ab ?
Ich vermute mal, dass Du Dich auf das "name" beziehst? Aus technischen Gründen braucht ein Trigger einen Namen (wie auch eine Tabelle oder ein Index einen Namen braucht). Dieser Name wird von Dir (als Programmierer bzw. Anwender) nicht weiter gebraucht, der dient nur der internen Identifizierung. Der Trigger wird automatisch ausgelöst, wenn das entsprechende Ereignis (INSERT, UPDATE, DELETE) stattfindet.

Wenn's Deine Frage nicht beantwortet, bitte etwas präziser definieren, wo Dein Problem liegt.


Gruss,

Georg
Liebe Grüsse aus der Eifel,

Georg S. Lorrig
Redakteur der Wiki des Deutschprachigen Xbase-Entwickler e.V.
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15688
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: PostgreSQL "Trigger"

Beitrag von brandelh »

Wie du den "Trigger" anlegst steht immer unten im SQL Feld erklärt, wie auch alle anderen Aktionen die man in der GUI macht
in diesem Feld in den für dieses Ergebnis benötigten SQL code umgewandelt werden.
Also über CODE (z.B. auch Xbase++ Programm: SQL ausführen "CREATE CONSTRAINT TRIGGER name...") oder GUI wird der Trigger angelegt.

Der Trigger ist wie eine Lichtschranke am Fenster, Fenster geht auf, Lichtschranke löst Alarm bzw. Aktionen aus.
Der Einbrecher (hier Programmierer oder Anwender) muss nichts erledigen, seine normalen Handlungen lösen den Trigger und damit eine Hintergrundaktion aus.

In dem Beispiel wird eine - ich vermute mal stored procedure - isam_rowversion_update() ausgeführt, nachdem ein UPDATE auf CUSTOMER einen DATENSATZ geändert hat.
Und zwar für JEDEN DATENSATZ hintereinander. Diese Funktion wird vermutlich einen Zähler hochzählen, der Änderungen seit dem letzten Einlesen bemerken soll.

Das dürfte vom Zweck vergleichbar sein mit einer Routine, die Indexdateien nach Änderungen eines Datenfeldes aktualisiert.
Gruß
Hubert
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: PostgreSQL "Trigger"

Beitrag von AUGE_OHR »

georg hat geschrieben:Ein primary key z.B. ist ein constraint, d.h. es wird nur dann ein neuer Satz angelegt, wenn es keinen anderen Satz gibt, der den gleichen (primary) key besitzt.
JA ... jetzt verstehe ich auch den Zusammenhang mit "Primary Key", DANKE !
georg hat geschrieben:Wenn's Deine Frage nicht beantwortet, bitte etwas präziser definieren, wo Dein Problem liegt.
als Newbie weiss man manchmal nicht wie man sich "richtig" ausdrücken soll ... aber ich lerne ;)
gruss by OHR
Jimmy
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: PostgreSQL "Trigger"

Beitrag von AUGE_OHR »

brandelh hat geschrieben:Also über CODE (z.B. auch Xbase++ Programm: SQL ausführen "CREATE CONSTRAINT TRIGGER name...") oder GUI wird der Trigger angelegt.
ok ... und "wann" führe ich den Befehl aus ?
zuerst muss ich wohl die Table und Field anlegen. dann die "Triggerfunktionen" oder erst mit "INSERT..." die Table füllen ?
brandelh hat geschrieben:In dem Beispiel wird eine - ich vermute mal stored procedure - isam_rowversion_update() ausgeführt, nachdem ein UPDATE auf CUSTOMER einen DATENSATZ geändert hat.
Und zwar für JEDEN DATENSATZ hintereinander. Diese Funktion wird vermutlich einen Zähler hochzählen, der Änderungen seit dem letzten Einlesen bemerken soll.

Das dürfte vom Zweck vergleichbar sein mit einer Routine, die Indexdateien nach Änderungen eines Datenfeldes aktualisiert.
aja dafür hat Alaska, bei Einsatz des DbfUpsize.EXE, die stored procedure und "Triggerfunktionen" angelegt.

Frage : hat "CONSTRAINT" hier beim Trigger was mit dem "CONSTRAINT ... PRIMARY KEY (__record)" zu tun ?
gruss by OHR
Jimmy
georg
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2823
Registriert: Fr, 08. Feb 2008 21:29
Hat sich bedankt: 95 Mal
Danksagung erhalten: 13 Mal

Re: PostgreSQL "Trigger"

Beitrag von georg »

Hallo, Jimmy -


wie ich schon an anderer Stelle (da in Bezug auf die SQL Syntax) geschrieben habe, ist SQL ein Bausatz.

Das gilt auch für Elemente wie CONSTRAINTs.

Du kannst eine Tabelle füllen, zehn Jahre damit arbeiten, und DANN erst einen PRIMAY KEY hinzufügen. Geht. Eventuell.

Du kannst den PRIMAY KEY auch direkt beim Erstellen hinzufügen. Deine Entscheidung.

Es gibt aber einen Unterschied: Wenn Du den CONTRAINT später definierst, prüft der Server, ob die Bedingung von den bisher vorhandenen Daten erfüllt werden. Ist das nicht der Fall, dann wird der CONSTRAINT nicht angelegt.


Thema Trigger, noch ein Beispiel (hatte ich, denke ich, in 2011 im Hennies bereits gebracht): Wir hatten eine zentrale Tabelle, in der das Datum 5 stellig, also als TTMMJ gespeichert war. Das damals anstehende Thema Y2K kam für uns also alle 10 Jahre, und unsere Programme konnten damit umgehen, bis auf einige wenige. Also wurde beschlossen, die entsprechende Tabelle (galt auch für andere, aber bleiben wir bei dieser als Beispiel) um den entsprechenden Satz Datumsfelder zu erweitern. Dann kam ein Trigger an die Datei, der aufgrund der beiden Abbilder (der Trigger liefert bei dem Server das Before- und das After-Image) prüfte, welches der beiden Datumsfelder (altes Format, bzw. neues Format) geändert wurde. Entsprechend wurde das Gegenstück im anderen Format ebenfalls angepasst.

Wenn wir also von CONSTRAINTs reden, dann müssen das nicht zwingend Bedingungen sein, sondern man kann sich diese Mechanismen eben auch für andere Zwecke zu nutze machen. Man braucht eben nur ein wenig Phantasie.


Gruss,

Georg
Liebe Grüsse aus der Eifel,

Georg S. Lorrig
Redakteur der Wiki des Deutschprachigen Xbase-Entwickler e.V.
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: PostgreSQL "Trigger"

Beitrag von AUGE_OHR »

georg hat geschrieben:Es gibt aber einen Unterschied: Wenn Du den CONTRAINT später definierst, prüft der Server, ob die Bedingung von den bisher vorhandenen Daten erfüllt werden. Ist das nicht der Fall, dann wird der CONSTRAINT nicht angelegt.
ok ...

heisst das dann auch wenn ich

Code: Alles auswählen

"CONSTRAINT ... PRIMARY KEY (__record)"
schon bei der Anlage verwendet haben und der "kaputt" geht das er dann keinen Zugriff (öffnen) mehr hat ?

angenommen, per "INSERT ..." füge ich einen Record hinzu aber __record gibt es schon ...

Frage : dann ...
a.) "INSERT ..." wird nicht ausgeführt, abgewiesen ?
b.) "__record" bekommt "ungültigen" Wert ?
c.) "alles kaputt" ?
georg hat geschrieben: (der Trigger liefert bei dem Server das Before- und das After-Image)
das mit "AFTER" is denke ich klar, aber wo käme "BEFORE" in Betracht ?
gruss by OHR
Jimmy
georg
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2823
Registriert: Fr, 08. Feb 2008 21:29
Hat sich bedankt: 95 Mal
Danksagung erhalten: 13 Mal

Re: PostgreSQL "Trigger"

Beitrag von georg »

Hallo, Jimmy -


Deine Fragen werden langsam "esoterisch", eventuell auch deshalb, weil Du zuviel von DBF/NTX auf SQL übertragen willst. Ein SQL-Server ist eine zentrale Einheit, die sich um die Pflege der Daten und der Datenkonsistenz kümmert. Ein Programm, das mit DBF/NTX (oder auch FOXCDX) arbeitet, ist eines unter vielen, das in den Daten rummatscht. Das Ergebnis sind defekte Index-Dateien und andere Probleme, weil es keine "Zentralstelle" für Datenkonsistenz gibt.

Wie ein spezieller SQL Server sich verhält, wenn ein Index "defekt" ist, muss man der jeweiligen Dokumentation entnehmen. Normalerweise prüft der Server bei der ersten Anforderung nach seinem Start, ob ein verwendeter Index in Ordnung ist oder nicht. Ist der Index defekt, erstellt der Server diesen Index neu. Während dieser Zeit ist wahrscheinlich kein INSERT möglich.


Viele Antworten auf Deine Fragen kannst Du sehr schnell simulieren:

starte das PostgreSQL Interface,
CREATE DATABASE datenbank;
USE datenbank;
CREATE TABLE inserterror (Zugriff INT, Irgendwas CHAR(32), PRIMARY KEY (Zugriff));
INSERT INTO inserterror VALUES(1, 'heute');
INSERT INTO inserterror VALUES(1, 'morgen');

Unter MySQl erhältst Du nach jeder Anweisung eine Rückmeldung des Servers, die z.B. SQLExpress als result set zurückliefert. Für die letzte Anweisung liefert mir MySQL dann folgenden Hinweis:
ERROR 1062 (23000): Duplicate entry '1' for key 1
Ich vermute, dass PostgreSQL sich ähnlich verhält.

Probieren geht über Studieren ...


Gruss,

Georg

P.S.: Das Verhalten mit Before- und After-Image bezieht sich auf die DB/2 400, wie andere SQL Server das machen, kann ich Dir nicht sagen. Im Zweifelsfall sollten wir selbst ein Before-Image irgendwo abgelegt haben.
Liebe Grüsse aus der Eifel,

Georg S. Lorrig
Redakteur der Wiki des Deutschprachigen Xbase-Entwickler e.V.
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: PostgreSQL "Trigger"

Beitrag von AUGE_OHR »

hi,
georg hat geschrieben:Deine Fragen werden langsam "esoterisch"
...
Probieren geht über Studieren ...
als Newbie weiss man ja vieles noch nicht und dann kommen auch schon mal solche Fragen.
jetzt in der "Test" Phase kann man ja "rumprobieren" ... das will ich hinter mir haben wenn es wirklich losgeht.

ok, also "doppelte" sollte ein "PRIMARY KEY" nicht zulassen.
wenn ich bei Type "serial" wirklich "manuell" hoch zählen muss ( scheint so ) kann ich es da ja schon "verhindern".

jetzt kommt aber die nächste Frage : was wenn ich eine Nummer "auslasse" ?

ich habe mir die Frage auch schon gestellt wie das mit "__deleted" und "PACK" funktioniert ?
wenn die "__deleted" entfernt werden "müsste" man dann "__record" neu durch nummerieren ?

apropos "__deleted" : sollte / kann man das in den "PRIMARY KEY" mit einbauen ?

Code: Alles auswählen

"SELECT "+::cFields+" FROM "+::cTable+" PRIMARY KEY (__record) AND NOT __deleted "
gruss by OHR
Jimmy
UliTs
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2828
Registriert: Fr, 10. Feb 2006 9:51
Wohnort: Aachen
Hat sich bedankt: 259 Mal
Danksagung erhalten: 12 Mal
Kontaktdaten:

Re: PostgreSQL "Trigger"

Beitrag von UliTs »

AUGE_OHR hat geschrieben:

Code: Alles auswählen

"SELECT "+::cFields+" FROM "+::cTable+" PRIMARY KEY (__record) AND NOT __deleted "
Du hast sicher schon selbst bemerkt, dass das Quatsch ist :-) .
Die Schlüsselwörter "PRIMARY KEY" werden beim Erstellen einer Tabelle benutzt!
Wenn Du nur einen Datensatz mit bekanntem Wert "__record" haben möchtest der nicht als "gelöscht" markiert ist, lautet der Code:

Code: Alles auswählen

"SELECT "+::cFields+" FROM "+::cTable+" WHERE __record = "+str(nRecNo)+" AND NOT __deleted"
Uli
-------
Mitglied XuG Cologne
Mitglied XuG Osnabrück
georg
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2823
Registriert: Fr, 08. Feb 2008 21:29
Hat sich bedankt: 95 Mal
Danksagung erhalten: 13 Mal

Re: PostgreSQL "Trigger"

Beitrag von georg »

Hallo, Jimmy -


da stehst Du wieder vor einer Entscheidung ...

Code: Alles auswählen

DELETE FROM table WHERE bedingung
macht einen Satz tot, mausetot. NO RECOVERY (es sei denn, Du wühlst im Hex-Dump der Datenbank rum).

Alaska bildet mit den internen Feldern DBF-Strukturen ab, um eben doch noch ein RECALL durchführen zu können.

Wenn Du die pgDBE verwenden willst, musst Du solche Dinge berücksichtigen, allerdings denke ich, dass Alaska je nach SET DELETED ON/OFF diese Sätze rausfiltert oder durchlässt.


Nächster Punkt ... für Tabellen, bei denen Du nicht die Hoheit über den Schlüssel haben willst (musst), kannst Du AUTOINCREMENT verwenden. Damit wird bei der Anlage eines neuen Satzes automatisch der Wert auf Max(nKeyFeld) + 1 gesetzt.

1
2
3
neuer Satz: 4

1
3
5
neuer Satz: 6

Je nach Implementierung im Server kann Dir folgendes passieren: nehmen wir das letzte Beispiel, nach der Anlage des vierten Satzes (Schlüsselfeld hat den Wert 6 automatisch erhalten), führst Du ein DELETE FROM table aus, und legst einen neuen Satz an. Der bekommt dann als Schlüsselwert ... entweder 1, oder 7 - je nach dem, wie das AUTOINCREMENT implementiert ist.

Das ist einer der Gründe, warum ich AUTOINCREMENT vermeide, da ich in den meisten Fällen eben die Hoheit darüber haben will, welche Schlüsselwerte verwendet werden. Nehmen wir eine Mitarbeiterdatei mit unterschiedlichen Stammnummernkreisen (nein, ich verwende keine sprechenden Schlüssel, aber über diese Dinge entscheiden eben Personalabteilungsmitarbeiter), da wäre AUTOINCREMENT einfach tödlich.


PRIMARY KEY ist etwas völlig anderes als das UNIQUE unter Xbase, siehe die Diskussionen um "verschwundene" Sätze in Index-Dateien mit UNIQUE-Attribut. UNIQUE heisst bei einem SQL Server UNIQUE, d.h. einmalig. Die Anlage eines neuen Satzes mit gleichem Schlüssel wird geblockt, das Ändern eines Satzes (Schlüsselfeld), wodurch ein doppelter Schlüssel entstehen würde, wird ebenfalls geblockt.


Ein PRIMARY KEY kennt auch keine Bedingungen, d.h. PRIMARY KEY (KeyField) WHERE NOT _DELETED ist kein zulässiges Sprachkonstrukt. Warum? Wenn das Bedigungsfeld geändert wird, könnte plötzlich ein Duplicate Key entstehen, ohne dass das Schlüsselfeld betroffen ist.


Normalerweise kommt der SQL Server mit einem Konsole-Programm, um manuell mit dem Server zu "spielen" (arbeiten). Darin kannst Du recht ungefährlich eine Spiel-Database anlegen und ausprobieren und eben auch sehen, wie der Server reagiert und welche Fehlermeldungen er von sich gibt.

Gerade MySQL ist das sehr "gesprächig", so dass Du ein entsprechendes Feedback bekommst (SQLite meldete sich eigentlich nur bei Fehlern).


Gruss,

Georg
Liebe Grüsse aus der Eifel,

Georg S. Lorrig
Redakteur der Wiki des Deutschprachigen Xbase-Entwickler e.V.
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: PostgreSQL "Trigger"

Beitrag von AUGE_OHR »

hi,

ok das mit "NOT _DELETED" hab ich begriffen ... eben eine Newbie Frage ;)

AUTOINCREMENT : aja ... nun kommen wir der Sache von Alaska auf die Spur.
AUTOINCREMENT.PNG
AUTOINCREMENT.PNG (40.39 KiB) 15559 mal betrachtet
Alaska legt wohl "Sequenzen" an ... oder macht das PG wenn man Type "serial" verwendet ?

PG Handbuch, S. 167, "9.11 Funktionen zur Bearbeitung von Sequenzen"
ich habe beim "Import" jedenfalls nicht "CREATE SEQUENCE ..." verwendet
die "Sequenzen" tauchen scheinbar bei allen "Test" Table mit Field "serial" auf.

nun denn ... die pgDBE scheint die zu "pflegen". ich "denke" man muss wohl "nextval()" zum hoch-zählen verwenden.
hm ... und wie mache ich das beim "Import" ?

Code: Alles auswählen

INSERT INTO FSICHER2 VALUES(1, ... )
INSERT INTO FSICHER2 VALUES(2, ... )

wird zu

INSERT INTO FSICHER2 VALUES( nextval(__record) , ... )
INSERT INTO FSICHER2 VALUES( nextval(__record) , ... )
gruss by OHR
Jimmy
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: PostgreSQL "Trigger"

Beitrag von AUGE_OHR »

hm ...
"wie" verwendet man richtig

Code: Alles auswählen

cSql := "SELECT setval("+xtab+"."+"__record,0) FROM "+xtab

cSql := "SELECT nextval("+xtab+"."+"__record) FROM "+xtab
meine Versuche enden im Errorlog so
2012-07-15 23:41:17 CEST NOTICE: CREATE TABLE will create implicit sequence "mw4___record_seq" for serial column "mw4.__record"
2012-07-15 23:41:17 CEST NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "mw4_pkey" for table "mw4"
2012-07-15 23:41:17 CEST ERROR: schema "mw4" does not exist
2012-07-15 23:41:17 CEST STATEMENT: SELECT setval('mw4.__record',0)
2012-07-15 23:41:17 CEST ERROR: syntax error at or near "nextval" at character 1
2012-07-15 23:41:17 CEST STATEMENT: nextval('mw4.__record')

...

2012-07-15 23:42:28 CEST NOTICE: CREATE TABLE will create implicit sequence "mw5___record_seq" for serial column "mw5.__record"
2012-07-15 23:42:28 CEST NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "mw5_pkey" for table "mw5"
2012-07-15 23:42:28 CEST ERROR: missing FROM-clause entry for table "mw5" at character 15
2012-07-15 23:42:28 CEST STATEMENT: SELECT setval(mw5.__record,0)
2012-07-15 23:42:28 CEST ERROR: syntax error at or near "nextval" at character 1
2012-07-15 23:42:28 CEST STATEMENT: nextval(mw5.__record)

...

2012-07-16 00:01:02 CEST LOG: loaded library "$libdir/plugins/plugin_debugger.dll"
2012-07-16 00:01:13 CEST NOTICE: CREATE TABLE will create implicit sequence "mw6___record_seq" for serial column "mw6.__record"
2012-07-16 00:01:13 CEST NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "mw6_pkey" for table "mw6"
2012-07-16 00:01:14 CEST ERROR: could not open relation with OID 1
2012-07-16 00:01:14 CEST STATEMENT: SELECT nextval(mw6.__record) FROM mw6
2012-07-16 00:01:14 CEST ERROR: could not open relation with OID 1
2012-07-16 00:01:14 CEST STATEMENT: SELECT nextval(mw6.__record) FROM mw6
p.s. alle Table kann ich mit pgAdmin.EXE öffnen / browsen.
gruss by OHR
Jimmy
bgl
Cut&Paste-Entwickler
Cut&Paste-Entwickler
Beiträge: 43
Registriert: Di, 30. Aug 2011 20:45

Re: PostgreSQL "Trigger"

Beitrag von bgl »

Eine Handvoll Definitionen:

PRIMARY KEY: Primary Key bedeutet im Prinzip eine Kombination der Schlüsselwörter INDEX NOT NULL UNIQUE.

TRIGGER: Ein Trigger ist eine Auslösemechanismus, das Gegenstück zu Events in Javascript z.B. würde ich sagen. Das Bedeutet, dass ein Trigger ein Funktionsaufruf ist, der stattfindet, wenn die auslösende Bedingung durchgeführt wird.

CONSTRAINT TRIGGER ist ein Weg TRIGGER anzulegen, der imHo wenig Vorteile und eine Reihe von Nachteilen mit sich bringt, z.B., dass er nur AFTER INSERT/UPDATE/DELETE aber nicht BEFORE erlaubt.

Normalerweise ist das anlegen von TRIGGERn eine 2 Schritte Angelegenheit, ich liefere mal eine dummy-tabelle dazu, um ein Beispiel zeigen zu können:

Code: Alles auswählen

CREATE LANGUAGE plpgsql;

CREATE TABLE demo_table (
    id          SERIAL PRIMARY KEY,
    htm_id      TEXT NOT NULL,
    some_value  TEXT
);

CREATE OR REPLACE FUNCTION demo_table_before_insert() RETURNS TRIGGER AS $$
DECLARE
BEGIN
    NEW.htm_id := 'id-' || NEW.id::TEXT;
    RETURN NEW;
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER trigger_demo_table_before_insert BEFORE INSERT ON demo_table FOR EACH ROW EXECUTE PROCEDURE demo_table_before_insert();

INSERT INTO demo_table (some_value) VALUES ('asdf qwer tzuiop');
-- creates a rowset in demo_table (id, htm_id, some_value) containing values (1, 'id-1', 'asdf qwer tzuiop')
Im -1. Schritt aktiviere ich plpgsql als gültige sprache für STORED PROCEDURES.

Im 0. Schritt definiere ich die Tabelle, das ist nur, damit der Trigger nachvollziehbar wird.

Der 1. eigentliche Schritt ist es, die Trigger-Funktion zu definieren.

Der 2. Schritt definiert den Trigger, der auf die Funktion zugreift. Dieser Trigger wird VOR dem Einfügen eines neuen Datensatzes ausgeführt und ruft die Funktion auf.
In NEW befindet sich das neue ROWSET.

Wäre es ein Update-Trigger, so hätte ich in OLD das alte ROWSET ebenfalls zur Verfügung.

Disclaimer: der Democode ist nicht getestet, für Nebenwirkungen und Laufzeitfehler daher keine Haftung ;-)
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: PostgreSQL "Trigger"

Beitrag von AUGE_OHR »

hi,

danke für die Antworten. in der "lates" Version des Import DBF -> PG hab ich nun auch die Trigger mit eingebaut.

Code: Alles auswählen

   cQuery := "CREATE TRIGGER "+ xtab +"_isam_rowversion AFTER UPDATE ON "+;
                                xtab +" FOR EACH ROW EXECUTE PROCEDURE isam_rowversion_update()"
   oPG:exec( cQuery )


   cQuery := "CREATE TRIGGER "+ xtab +"_isam_tablemeta AFTER INSERT OR UPDATE OR DELETE ON "+;
                                xtab +"  FOR EACH ROW EXECUTE PROCEDURE isam_tablemeta_update()"
   oPG:exec( cQuery )
damit "müsste" ich nun pgDBE "kompatible" sein
gruss by OHR
Jimmy
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: PostgreSQL "Trigger"

Beitrag von AUGE_OHR »

es sieht gut aus, also setzte ich diesen Thread auf [erledigt]
gruss by OHR
Jimmy
Antworten