Interessantes Problem. Das ist meine beste Vermutung. Ich habe nichts davon getestet.
Im Allgemeinen erstreckt sich die fundierte Vermutung von Postgres darüber, welche Auswirkungen Aussagen auf Daten haben werden, nicht auf die Auslöselogik. Beim Ausführen der zweiten Anweisung sieht postgres die Fremdschlüsseleinschränkung und weiß, dass es prüfen muss, ob der zugewiesene (eingefügte) Wert gültig ist, dh ob er einen gültigen Schlüssel in der Fremdtabelle darstellt. Es ist möglich, aber schlechte Praxis, dass der Auslöser einen Einfluss auf die Gültigkeit des vorgeschlagenen Fremdschlüssels hat (z. B. wenn der Auslöser Datensätze löscht).
(Fall 1) Wenn es keinen Auslöser gibt, kann es die Daten (sowohl Pre-Commit als auch Staging for Commit) betrachten und entscheiden, ob der vorgeschlagene Wert garantiert gültig ist. (Fall 2) Wenn es keine FK-Einschränkung gibt, dann kann der Auslöser die Gültigkeit der Einfügung nicht beeinflussen, also ist sie erlaubt. (Fall 3) Wenn Sie detail_id=null weglassen , gibt es keine Änderung in der Aktualisierung, sodass der Trigger nicht ausgelöst wird, sodass sein Vorhandensein irrelevant ist.
Ich versuche, sowohl FK-Einschränkungen als auch Auslöser zu vermeiden, wann immer dies möglich ist. Meiner Meinung nach ist es besser, die Datenbank versehentlich teilweise falsche Daten enthalten zu lassen, als sie vollständig hängen zu lassen, wie Sie es hier sehen. Ich würde alle FK-Einschränkungen und -Trigger löschen und alle Aktualisierungs- und Einfügevorgänge dazu zwingen, über gespeicherte Funktionen zu arbeiten, die eine Validierung innerhalb einer Begin/Commit-Sperre durchführen und falsche/ungültige Einfüge-/Aktualisierungsversuche angemessen und sofort handhaben, anstatt Postgres dazu zu zwingen Warten Sie, bis Befehl 1 übergeben wird, bevor Sie entscheiden, ob Befehl 2 zulässig ist.
Bearbeiten: siehe diese Frage
Änderung 2: Das, was ich der offiziellen Dokumentation zum Timing von Triggern in Bezug auf die Überprüfung von Einschränkungen am nächsten kommen kann, ist dies aus löst Dokumente aus
Dies ist etwas unklar, wenn der Trigger, der vor der Einschränkungsprüfung auftritt, für die Einschränkungsprüfung anderer Transaktionen gilt. Wie dem auch sei, dieses Problem ist entweder ein Fehler oder schlecht dokumentiert.
