• Tom Lane's avatar
    Fix incorrect optimization of foreign-key checks. When an UPDATE on the · 2c535bfe
    Tom Lane authored
    referencing table does not change the tuple's FK column(s), we don't bother
    to check the PK table since the constraint was presumably already valid.
    However, the check is still necessary if the tuple was inserted by our own
    transaction, since in that case the INSERT trigger will conclude it need not
    make the check (since its version of the tuple has been deleted).  We got this
    right for simple cases, but not when the insert and update are in different
    subtransactions of the current top-level transaction; in such cases the FK
    check would never be made at all.  (Hence, problem dates back to 8.0 when
    subtransactions were added --- it's actually the subtransaction version of a
    bug fixed in 7.3.5.)  Fix, and add regression test cases.  Report and fix by
    Affan Salman.
    2c535bfe
foreign_key.sql 27.4 KB