"Peter Koczan" <pjkoczan@gmail.com> writes:
>> If your original database doesn't have all three triggers, then you had
>> a problem already --- the FK constraint wasn't being enforced properly.
> Ah, these were from before I became the main database admin. It was
> probably some previous admin or programmer who thought he could be
> clever and drop the other FK-related triggers.
Or it could just be a long-ago oversight. In versions before about 7.3,
it was possible to drop and recreate one of the two tables involved in
an FK relationship without any impact on the other table's FK
trigger(s). Depending on usage patterns you might never notice that
the FK constraint was now only partially enforced.
Hmm, actually the note in the code says that there were two separate
bad things that had to happen to get into this situation:
* The conversion is complex because a pre-7.3 foreign key involved three
* separate triggers, which were reported separately in dumps. While the
* single trigger on the referencing table adds no new information, we need
* to know the trigger functions of both of the triggers on the referenced
* table to build the constraint declaration. Also, due to lack of proper
* dependency checking pre-7.3, it is possible that the source database had
* an incomplete set of triggers resulting in an only partially enforced
* FK constraint. (This would happen if one of the tables had been dropped
* and re-created, but only if the DB had been affected by a 7.0 pg_dump bug
* that caused loss of tgconstrrelid information.)
regards, tom lane
