Интересен проблем. Това е най-доброто ми предположение. Не съм тествал нищо от това.
Най-общо казано, образованото предположение на postgres за това какъв ефект ще имат изразите върху данните, не се простира в логиката на задействане. Когато изпълнява втория оператор, postgres вижда ограничението за външен ключ и знае, че трябва да провери дали присвоената (вмъкната) стойност е валидна, т.е. дали представлява валиден ключ във външната таблица. Възможно е, колкото и лоша практика да е, тригерът да има ефект върху валидността на предложения външен ключ (напр. ако тригерът изтрива записи).
(случай 1) Ако няма тригер, тогава той може да прегледа данните (както предварително ангажиране, така и настроени за ангажиране) и да реши дали предложената стойност е гарантирано валидна. (случай 2) Ако няма FK ограничение, тогава тригерът не може да повлияе на валидността на вмъкването, така че е разрешено. (случай 3) Ако пропуснете detail_id=null , няма промяна в актуализацията, така че тригерът няма да се задейства, така че присъствието му е без значение.
Опитвам се да избягвам както FK ограниченията, така и тригерите, когато е възможно. По мое мнение е по-добре да оставите базата данни случайно да съдържа частично неправилни данни, отколкото тя да виси напълно, както виждате тук. Бих премахнал всички FK ограничения и задействания и бих принудил всички операции за актуализиране и вмъкване да работят чрез съхранени функции, които извършват валидиране в рамките на заключване за начало/комитиране и обработват неправилни/невалидни опити за вмъкване/актуализиране по подходящ и незабавен начин, вместо да принуждават postgres да изчакайте команда 1 да се ангажира, преди да решите дали команда 2 е разрешена.
Редактиране: вижте този въпрос
Редактиране 2: Най-близкото нещо, което мога да намеря до официалната документация относно времето на тригерите по отношение на проверката на ограниченията, е това от задейства документи
Това е малко неясно, ако задействането, което се случва преди проверката на ограниченията, се прилага за проверка на ограниченията на други транзакции. Какъвто и да е случаят, този проблем е или грешка, или е лошо документиран.
