1. 27 Jul, 2007 2 commits
  2. 26 Jul, 2007 1 commit
  3. 25 Jul, 2007 9 commits
  4. 24 Jul, 2007 5 commits
  5. 23 Jul, 2007 5 commits
  6. 21 Jul, 2007 2 commits
  7. 20 Jul, 2007 3 commits
  8. 19 Jul, 2007 4 commits
  9. 18 Jul, 2007 7 commits
  10. 17 Jul, 2007 2 commits
    • 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
    • Bruce Momjian's avatar
      Remove http://www.benchmarkresources.com, no longer resolves to a · a5ca334a
      Bruce Momjian authored
      meaningful site.
      a5ca334a