興味深い問題。これが私の一番の推測です。どれもテストしていません。
一般的に言って、postgresが知識に基づいてステートメントがデータに与える影響を推測することは、トリガーロジックには及びません。 2番目のステートメントを実行すると、postgresは外部キー制約を確認し、割り当てられている（挿入されている）値が有効かどうか、つまり外部テーブルの有効なキーを表しているかどうかを確認する必要があることを認識します。ただし、悪い習慣として、トリガーが提案されている外部キーの有効性に影響を与える可能性があります（たとえば、トリガーがレコードを削除した場合）。
（ケース1）トリガーがない場合は、データ（事前コミットとコミットのステージングの両方）を調べて、提案された値が有効であることが保証されているかどうかを判断できます。 （ケース2）FK制約がない場合、トリガーは挿入の有効性に影響を与えることができないため、許可されます。 （ケース3）detail_id=nullを省略した場合 、更新に変更がないため、トリガーは起動しないため、その存在は関係ありません。
可能な限り、FK制約とトリガーの両方を回避するようにしています。私の意見では、データベースに誤って部分的に正しくないデータが含まれているようにしてから、ここに表示されているように完全にハングさせる方がよいと思います。すべてのFK制約とトリガーを削除し、すべての更新操作と挿入操作を、begin / commitロック内で検証を実行し、postgresを強制するのではなく、誤った/無効な挿入/更新の試行を適切かつ即座に処理する保存された関数を介して操作するように強制します。コマンド1がコミットするのを待ってから、コマンド2を許可するかどうかを決定します。
編集： この質問 を参照してください
編集2： 制約のチェックに関連するトリガーのタイミングに関する公式ドキュメントに最も近いものは、トリガードキュメント
制約チェックの前に発生したトリガーが他のトランザクションの制約チェックに適用される場合、これは少し不明確です。いずれにせよ、この問題はバグであるか、文書化が不十分です。