Trigger Deaktivieren

Probleme und Fragen zum Thema Trigger und Funktionen.
Antworten
henrik
Benutzer
Beiträge: 38
Registriert: Di 20. Dez 2005, 18:33
Wohnort: Neusorg
Kontaktdaten:

Trigger Deaktivieren

Beitrag von henrik »

Tag miteinander

gibt es eine möglichkeit alle Trigger einer Datenbank auf einmal zu deaktivieren ?

z.B. bevor man einen dump einspielt ?

mfg
henrik

Xandrian
Erfahrener Benutzer
Beiträge: 1695
Registriert: Mi 23. Nov 2005, 09:17
Wohnort: Bayreuth
Kontaktdaten:

Beitrag von Xandrian »

hi,

ist mir nichts bekannt und habe auch im netz nichts gefunden. solltest du das aus performance gründen machen wird dir nichts anderes übrig bleiben, wie alle trigger zu exportieren und nach dem einspielen des dumps wieder in die datenbank zu integrieren. was allerdings ein riesen aufwand ist...

cu tb.
pg-forum.de unterstützen? Meine Wunschliste

Bild

Fröstel
Neuer Benutzer
Beiträge: 28
Registriert: Di 31. Jan 2006, 15:11
Wohnort: Berlin

Trigger-Schalter

Beitrag von Fröstel »

Hi,

bin gerade über ein ähnliches Problem gestolpert.
Mit Hilfe eines Triggers verhindere ich, dass in einer Tabelle Einträge mit einem bestimmten Wert in einer Spalte durch UPDATE nicht verändert und durch DELETE nicht gelöscht werden können, da sie das Ergebnis eines Prozesses beinhalten
Da ich aber die Tabelle regelmäßig leere, um sie für einen neuen Prozess wieder zu verwenden, steht mir der Trigger dabei im Wege. Will meinen, die entsprechenden Einträge krieg ich natürlich nicht weg.
Deshalb hab ich mir 'nen Trigger-Ein/Aus-Schalter gebastelt - einfach eine Funktion, die einen Boole'schen Wert entgegennimmt und den Trigger dropt oder kreiert. Ich bin mir zwar gerade nicht so wirklich sicher, ob das nun eine elegante Lösung :idea: oder ein schmutziger Hack :twisted: ist, aber das ist erstmal nebensächlich. :?

:!: Nun zum o.g. Problem:
Man könnte doch die entsprechende Funktion komplett dynamisch anlegen (siehe Kapitel 38.6.4 Dynamische Befehle ausführen in PL/pgSQL). Mit Hilfe eines LOOP dropt sie alle Trigger. Dann wird der/die/das Dump erledigt, bevor die Trigger alle wieder zusammengebaut werden.
Das droppen geht ja noch recht einfach, da reicht der Name des Triggers und der Tabelle. Das Wiederzusammenbauen wird etwas anstrengender. Wenn man aber die entsprechenden Infos in einer Tabelle vorhält, sollte das auch alles problemlos und konsistent ablaufen.

CU
frö
-------------------------------------------------------------
Information is a weapon of mass destruction
[Faithless]
-------------------------------------------------------------

fristo
Erfahrener Benutzer
Beiträge: 670
Registriert: Do 8. Dez 2005, 12:30
Wohnort: Raum Frankfurt/Main

Re: Trigger-Schalter

Beitrag von fristo »

Fröstel hat geschrieben:bin gerade über ein ähnliches Problem gestolpert.
Mit Hilfe eines Triggers verhindere ich, dass in einer Tabelle Einträge mit einem bestimmten Wert in einer Spalte durch UPDATE nicht verändert und durch DELETE nicht gelöscht werden können, da sie das Ergebnis eines Prozesses beinhalten
Da ich aber die Tabelle regelmäßig leere, um sie für einen neuen Prozess wieder zu verwenden, steht mir der Trigger dabei im Wege. Will meinen, die entsprechenden Einträge krieg ich natürlich nicht weg.
Deshalb hab ich mir 'nen Trigger-Ein/Aus-Schalter gebastelt - einfach eine Funktion, die einen Boole'schen Wert entgegennimmt und den Trigger dropt oder kreiert. Ich bin mir zwar gerade nicht so wirklich sicher, ob das nun eine elegante Lösung :idea: oder ein schmutziger Hack :twisted: ist, aber das ist erstmal nebensächlich. :?


Hack? Wofür?

PostgreSQL 8.1.2 Documentation:
ALTER TABLE [ ONLY ] name [ * ]
action [, ... ]

where action is one of:

...
DISABLE TRIGGER [ trigger_name | ALL | USER ]
ENABLE TRIGGER [ trigger_name | ALL | USER ]
...



Fröstel hat geschrieben::!: Nun zum o.g. Problem:
Man könnte doch die entsprechende Funktion komplett dynamisch anlegen (siehe Kapitel 38.6.4 Dynamische Befehle ausführen in PL/pgSQL). Mit Hilfe eines LOOP dropt sie alle Trigger. Dann wird der/die/das Dump erledigt, bevor die Trigger alle wieder zusammengebaut werden.
Das droppen geht ja noch recht einfach, da reicht der Name des Triggers und der Tabelle. Das Wiederzusammenbauen wird etwas anstrengender. Wenn man aber die entsprechenden Infos in einer Tabelle vorhält, sollte das auch alles problemlos und konsistent ablaufen.


Man kann es einfach oder aufwendig machen! Alle Information hierzu stehen doch in den System-Tabellen. Oder?



mfg

fristo

Fröstel
Neuer Benutzer
Beiträge: 28
Registriert: Di 31. Jan 2006, 15:11
Wohnort: Berlin

Beitrag von Fröstel »

Hi

Hack? Wofür?

PostgreSQL 8.1.2 Documentation:


Ich betreibe noch 'ne Version 8.0.2 da gibt's das nette Feature leider noch nicht :( - wurde erst mit 8.1 eingeführt! (siehe Release Notes) ... Vielleicht sollte ich mal updaten.

Man kann es einfach oder aufwendig machen! Alle Information hierzu stehen doch in den System-Tabellen. Oder?


Klar, hätte ich ja wohl auch selbst drauf kommen können, danke für den Hinweis! :o ops:

CU
frö
-------------------------------------------------------------
Information is a weapon of mass destruction
[Faithless]
-------------------------------------------------------------

ads
Erfahrener Benutzer
Beiträge: 4151
Registriert: Mi 8. Feb 2006, 10:58
Wohnort: MD
Kontaktdaten:

Beitrag von ads »

Alternativ einmal einen Dump der Datenbank durchführen, der pg_dump Befehl deaktiviert auch alle Trigger, den entsprechenden Code kann man dann im Output nachlesen ;-)
Xandrian: Kurz gesagt: Du hast ein falsches Konzept und willst nicht auf ads hören Bild

Jetzt NEU: PostgreSQL - Datenbankpraxis für Anwender, Administratoren und Entwickler

PostgreSQL Service & Support

Antworten