Skip to content
Snippets Groups Projects
Select Git revision
  • benchmark-tools
  • postgres-lambda
  • master default
  • REL9_4_25
  • REL9_5_20
  • REL9_6_16
  • REL_10_11
  • REL_11_6
  • REL_12_1
  • REL_12_0
  • REL_12_RC1
  • REL_12_BETA4
  • REL9_4_24
  • REL9_5_19
  • REL9_6_15
  • REL_10_10
  • REL_11_5
  • REL_12_BETA3
  • REL9_4_23
  • REL9_5_18
  • REL9_6_14
  • REL_10_9
  • REL_11_4
23 results

syscache.c

Blame
    • Tom Lane's avatar
      7bddca34
      Fix up foreign-key mechanism so that there is a sound semantic basis for the · 7bddca34
      Tom Lane authored
      equality checks it applies, instead of a random dependence on whatever
      operators might be named "=".  The equality operators will now be selected
      from the opfamily of the unique index that the FK constraint depends on to
      enforce uniqueness of the referenced columns; therefore they are certain to be
      consistent with that index's notion of equality.  Among other things this
      should fix the problem noted awhile back that pg_dump may fail for foreign-key
      constraints on user-defined types when the required operators aren't in the
      search path.  This also means that the former warning condition about "foreign
      key constraint will require costly sequential scans" is gone: if the
      comparison condition isn't indexable then we'll reject the constraint
      entirely. All per past discussions.
      
      Along the way, make the RI triggers look into pg_constraint for their
      information, instead of using pg_trigger.tgargs; and get rid of the always
      error-prone fixed-size string buffers in ri_triggers.c in favor of building up
      the RI queries in StringInfo buffers.
      
      initdb forced due to columns added to pg_constraint and pg_trigger.
      7bddca34
      History
      Fix up foreign-key mechanism so that there is a sound semantic basis for the
      Tom Lane authored
      equality checks it applies, instead of a random dependence on whatever
      operators might be named "=".  The equality operators will now be selected
      from the opfamily of the unique index that the FK constraint depends on to
      enforce uniqueness of the referenced columns; therefore they are certain to be
      consistent with that index's notion of equality.  Among other things this
      should fix the problem noted awhile back that pg_dump may fail for foreign-key
      constraints on user-defined types when the required operators aren't in the
      search path.  This also means that the former warning condition about "foreign
      key constraint will require costly sequential scans" is gone: if the
      comparison condition isn't indexable then we'll reject the constraint
      entirely. All per past discussions.
      
      Along the way, make the RI triggers look into pg_constraint for their
      information, instead of using pg_trigger.tgargs; and get rid of the always
      error-prone fixed-size string buffers in ri_triggers.c in favor of building up
      the RI queries in StringInfo buffers.
      
      initdb forced due to columns added to pg_constraint and pg_trigger.