On Sun, 2005-05-29 at 23:09 -0400, Tom Lane wrote:
> Looks OK to me. Don't forget that the first of these should probably
> include a catversion.h bump.
Both patches applied to HEAD, catversion bumped. Thanks for the
comments, Tom.
-Neil
---(end of broadcast)--
Neil Conway <[EMAIL PROTECTED]> writes:
> Attached are two patches: one that changes ADD FOREIGN KEY to create
> separate ON INSERT and ON UPDATE triggers that invoke different trigger
> functions, and a revised version of the FK UPDATE enqueuing patch.
Looks OK to me. Don't forget that the first
On Sun, 2005-05-29 at 21:06 -0400, Tom Lane wrote:
> Neil Conway <[EMAIL PROTECTED]> writes:
> > Hmm, I suppose -- if you prefer I can have check_ins called by the
> > INSERT trigger and check_upd called by the UPDATE trigger, which
> > probably makes more sense.
>
> Yeah ... I thought it was do
Neil Conway <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> What's the point of removing the distinction between check_ins and
>> check_upd functions?
> I talked about this in an earlier message to -hackers: check_upd was
> actually unused (check_ins was used for both inserts and updates).
Hm,
Tom Lane wrote:
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 talked about this in an earlier message to -hackers: check_upd was
actually unused (check_ins was used for both insert
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_k
This patch implements an idea discussed on -hackers recently: if an
UPDATE on a table with a foreign key does not modify any of the table's
foreign key columns, we can avoid enqueueing the foreign queue check
trigger.
I basically just moved the logic for the "are the keys equal?" test from
th
