• Tom Lane's avatar
    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
trigger.c 91.5 KB