problema interesante Esta es mi mejor conjetura. No he probado nada de eso.
En términos generales, las conjeturas educadas de postgres sobre qué efecto tendrán las declaraciones en los datos no se extienden a la lógica de activación. Al ejecutar la segunda declaración, postgres ve la restricción de clave externa y sabe que tiene que verificar si el valor que se asigna (inserta) es válido, es decir, si representa una clave válida en la tabla externa. Es posible, aunque sea una mala práctica, que el activador tenga un efecto sobre la validez de la clave externa que se propone (por ejemplo, si el activador elimina registros).
(caso 1) Si no hay un activador, entonces puede mirar los datos (tanto antes de la confirmación como preparados para la confirmación) y decidir si el valor propuesto es válido. (caso 2) Si no hay una restricción FK, entonces el activador no puede afectar la validez de la inserción, por lo que está permitida. (caso 3) Si omite el detail_id=null , no hay cambios en la actualización, por lo que el activador no se activará, por lo que su presencia es irrelevante.
Trato de evitar tanto las restricciones FK como los disparadores siempre que sea posible. En mi opinión, es mejor dejar que la base de datos contenga accidentalmente datos parcialmente incorrectos que dejar que se cuelgue por completo, como está viendo aquí. Quitaría todas las restricciones y disparadores de FK, y obligaría a todas las operaciones de actualización e inserción a operar a través de funciones almacenadas, que realizan la validación dentro de un bloqueo de inicio / confirmación, y manejaría los intentos de inserción / actualización incorrectos / no válidos de manera adecuada e inmediata, en lugar de obligar a postgres a espere a que se confirme el comando 1 antes de decidir si se permite el comando 2.
Editar: consulte esta pregunta
Edición 2: Lo más parecido que puedo encontrar a la documentación oficial sobre el tiempo de activación en relación con la verificación de restricciones es esto de documentos de activadores
Esto es un poco confuso, si el desencadenante que ocurre antes de la verificación de restricciones se aplica a la verificación de restricciones de otras transacciones. En cualquier caso, este problema es un error o está mal documentado.
