Interessant probleem. Dit is mijn beste gok. Ik heb er niets van getest.
Over het algemeen geldt dat postgres' weloverwogen gissing van het effect van uitspraken op gegevens niet wordt uitgebreid tot triggerlogica. Bij het uitvoeren van de tweede instructie ziet postgres de externe sleutelbeperking en weet dat het moet controleren of de waarde die wordt toegewezen (ingevoegd) geldig is, dat wil zeggen of het een geldige sleutel in de buitenlandse tabel vertegenwoordigt. Het is mogelijk, hoe slecht ook, dat de trigger een effect kan hebben op de geldigheid van de refererende sleutel die wordt voorgesteld (bijvoorbeeld als de trigger records verwijdert).
(geval 1) Als er geen trigger is, kan het naar de gegevens kijken (zowel pre-commit als staged for commit) en beslissen of de voorgestelde waarde gegarandeerd geldig is. (geval 2) Als er geen FK-beperking is, kan de trigger de geldigheid van de invoeging niet beïnvloeden, dus is deze toegestaan. (geval 3) Als u de detail_id=null . weglaat , er is geen verandering in de update, dus de trigger wordt niet geactiveerd, dus de aanwezigheid ervan is niet relevant.
Ik probeer waar mogelijk zowel FK-beperkingen als triggers te vermijden. Het is mijns inziens beter om de database per ongeluk gedeeltelijk incorrecte gegevens te laten bevatten dan om deze volledig te laten vastlopen, zoals je hier ziet. Ik zou alle FK-beperkingen en triggers laten vallen en alle update- en invoegbewerkingen dwingen om te werken via opgeslagen functies, die validatie uitvoeren binnen een begin/commit-slot, en onjuiste/ongeldige invoeg-/updatepogingen op de juiste en onmiddellijke manier afhandelen, in plaats van postgres te dwingen om wacht tot opdracht 1 is vastgelegd voordat je beslist of opdracht 2 is toegestaan.
Bewerken: zie deze vraag
Bewerken 2: Het dichtst bij officiële documentatie over de timing van triggers met betrekking tot het controleren van beperkingen, is dit van de triggert documenten
Dit is een beetje onduidelijk, als de trigger die plaatsvindt vóór de beperkingscontrole van toepassing is op de beperkingscontrole van andere transacties. Hoe dan ook, dit probleem is ofwel een bug of slecht gedocumenteerd.