Neil Conway <[EMAIL PROTECTED]> 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
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])