Skip site navigation (1) Skip section navigation (2)

Re: skip FK trigger on UPDATE

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Neil Conway <neilc(at)samurai(dot)com>
Cc: PostgreSQL-patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: skip FK trigger on UPDATE
Date: 2005-05-29 15:38:14
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-patches
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

			regards, tom lane

In response to


pgsql-patches by date

Next:From: Tom LaneDate: 2005-05-29 17:19:24
Subject: Re: pg_buffercache causes assertion failure
Previous:From: Michael FuhrDate: 2005-05-29 15:19:54
Subject: pg_buffercache causes assertion failure

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group