Interessant problem. Dette er mit bedste gæt. Jeg har ikke testet noget af det.
Generelt set strækker postgres' veluddannede gæt om, hvilken effekt udsagn vil have på data sig ikke ind i triggerlogik. Når den anden sætning udføres, ser postgres den fremmede nøgle-begrænsning og ved, at den skal kontrollere, om den værdi, der tildeles (indsættes), er gyldig, dvs. om den repræsenterer en gyldig nøgle i den fremmede tabel. Det er muligt, uanset hvor dårlig praksis det end er, at triggeren kan have en effekt på gyldigheden af den fremmede nøgle, der foreslås (f.eks. hvis udløseren sletter poster).
(tilfælde 1) Hvis der ikke er nogen trigger, så kan den se på dataene (både pre-commit og staged for commit) og beslutte, om den foreslåede værdi er garanteret gyldig. (tilfælde 2) Hvis der ikke er nogen FK-begrænsning, kan triggeren ikke påvirke gyldigheden af indsættelsen, så det er tilladt. (tilfælde 3) Hvis du udelader detail_id=null , er der ingen ændring i opdateringen, så triggeren udløses ikke, så dens tilstedeværelse er irrelevant.
Jeg forsøger at undgå både FK-begrænsninger og triggere, når det er muligt. Det er bedre, efter min mening, at lade databasen ved et uheld indeholde delvist forkerte data, så at få det til at hænge helt, som du ser her. Jeg ville droppe alle FK-begrænsninger og triggere og tvinge alle opdaterings- og indsættelsesoperationer til at fungere via lagrede funktioner, som udfører validering inde i en start/commit-lås og håndtere forkerte/ugyldige indsættelses-/opdateringsforsøg korrekt og øjeblikkeligt, i stedet for at tvinge postgres til at vent på, at kommando 1 begår, før du beslutter, om kommando 2 er tilladt.
Rediger: se dette spørgsmål
Rediger 2: Det tætteste, jeg kan finde på officiel dokumentation omkring timingen af triggere i forhold til kontrol af begrænsninger, er dette fra udløser dokumenter
Dette er lidt uklart, hvis udløsningen sker før begrænsningskontrollen gælder begrænsningstjek af andre transaktioner. Uanset hvad, er dette problem enten en fejl eller dårligt dokumenteret.