Ermitteln Sie die Quelle eines Triggers in Postgresql

9

Glauben Sie, dass es möglich ist, die Quelle einer Triggerausführung in PostgreSQL zu bestimmen? Nehmen wir an, ich habe zwei Tabellen wie folgt:

%Vor%

Dabei verweist tbl2 auf tbl1 mit einem "ON DELETE CASCADE".

Definieren wir außerdem einen Trigger für tbl2, der nach dem Löschen einer ROW ausgeführt wird:

%Vor%

Der Trigger wird immer ausgeführt, nachdem eine Zeile in tbl2 gelöscht wurde, unabhängig davon, ob die Zeilen direkt oder durch eine Kaskade entfernt wurden. Zum Beispiel feuern beide folgenden Aussagen schließlich den Auslöser:

%Vor%

Innerhalb der test_fn (), ist es möglich, die beiden Fälle zu unterscheiden? I.e. herauszufinden, warum die Reihe entfernt wurde? Ich habe versucht, den Grund für die Verwendung des Stacks zu ermitteln (d. H. Mit GET DIAGNOSTICS stack = PG_CONTEXT), aber es kam nichts heraus.

Kann mir hier jemand helfen? Vielen Dank im Voraus

    
Ciaccia 17.12.2015, 10:50
quelle

2 Antworten

2

Der Kontext der Operation (d.h. kaskadiertes Löschen oder einfaches Löschen) sollte irgendwo gespeichert werden. Sie können einen benutzerdefinierten Parameter für diesen Zweck verwenden. Wenn das kaskadierte Löschen (aus Tabelle tbl1 ) ausgeführt wird, werden Trigger in der folgenden Reihenfolge ausgelöst:

%Vor%

Sie benötigen daher zwei Trigger (vor und nach dem Löschen) in der Tabelle tbl1 und einen Trigger vor dem Löschen in der Tabelle tbl2 .

Erstellen Sie zwei Trigger für tbl1 . Setzen Sie den benutzerdefinierten Parameter auf on in der Funktion vor dem Trigger und auf off in der Funktion nach dem Trigger:

%Vor%

In tbl2 Triggerfunktion überprüfen Sie den aktuellen Wert des Parameters. Ausnahmeblock ist notwendig, falls der Parameter noch nicht gesetzt wurde:

%Vor%

Test:

%Vor%

Alternative Lösung.

Wenn der Trigger vor dem Löschen in der Tabelle tbl2 im Kontext des kaskadierten Löschens ausgeführt wird, wird der Diagnosewert PG_EXCEPTION_CONTEXT auf eine Zeichenfolge gesetzt und ist leer, wenn die Löschung nicht kaskadiert ist:

%Vor%

Diese Lösung mag in diesem Sinne fragwürdig sein, dass sie nur aus Tests resultiert, dieses Verhalten ist nirgends dokumentiert.

    
klin 16.01.2016 00:51
quelle
1

Haben Sie versucht, EXPLAIN ANALYSE für die Abfrage zu verwenden, um zu sehen, was der PostgreSQL-Abfrageanalysator ausgibt. Laut PostgreSQL Version 9.4 wird Postgres

anzeigen

"Die von EXPLAIN ANALYZE angezeigte Ausführungszeit enthält die Start- und Abschaltdauer des Executors sowie die Zeit für die Ausführung aller ausgelösten Trigger. Parsing, Neuschreiben und Planungszeit werden jedoch nicht berücksichtigt Ausführen von BEFORE-Triggern ist, wenn vorhanden, in der Zeit für den zugehörigen Knoten Einfügen, Aktualisieren oder Löschen enthalten, aber die Zeit, die AFTER-Trigger ausgeführt werden, wird dort nicht gezählt, da AFTER-Trigger nach Abschluss des gesamten Plans ausgelöst werden Jeder Trigger (entweder VOR oder NACH) wird ebenfalls separat angezeigt. Beachten Sie, dass Trigger für verzögerte Abhängigkeiten erst am Ende der Transaktion ausgeführt werden und daher von EXPLAIN ANALYSE überhaupt nicht berücksichtigt werden. "

(Quell-URL: Ссылка )

Wenn Sie PostgreSQL v9.1 verwenden, müssen Sie jedoch EXPLAIN ANALYSE mit VERBOSE verwenden, um die gleiche Funktionalität zu erhalten ( Ссылка )

    
unxn3rd 22.01.2016 19:27
quelle