Re: skip FK trigger on UPDATE

Neil Conway <neilc(at)samurai(dot)com> writes:
> I basically just moved the logic for the "are the keys equal?" test from
> the FK trigger itself into the code that enqueues the trigger. I then
> removed the keys-are-equal check from the FK trigger. I also had to
> change (somewhat awkwardly) RI_FKey_keyequal_upd() to work for updates
> on either the PK table or the FK table. I also removed the bogus
> TriggerData argument from RI_FKey_keyequal_upd(), since AFAICS it is no
> needed and merely adds confusion.

It would probably be cleaner to have two keys-are-equal check routines
than to contort RI_FKey_keyequal_upd to work this way.

You seem to have also done a fair amount of unrelated hacking around.
What's the point of removing the distinction between check_ins and
check_upd functions? I think that may confuse existing client code
that looks at the triggers, without really buying much. A possibly
stronger argument is that if we find down the road that we need
separate functions again, we'll be in a bit of a sticky place; at
least if we need it to fix a bug without forcing initdb.

> This patch does cause one change to the regression test output:

That's discomforting --- you had better find out exactly why that
changed.

regards, tom lane