Date: Tue, 30 Sep 2003 08:29:54 -0700 (PDT)
From: Stephan Szabo <sszabo@megazone.bigpanda.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Bruce Momjian <pgman@candle.pha.pa.us>, Jan Wieck <JanWieck@Yahoo.com>,
	Christopher Kings-Lynne <chriskl@familyhealth.com.au>,
	Peter Childs <Blue.Dragon@blueyonder.co.uk>,
	PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: ADD FOREIGN KEY (was Re: [GENERAL] 7.4Beta) 
In-Reply-To: <19584.1064934958@sss.pgh.pa.us>
Message-ID: <20030930082522.L15622@megazone.bigpanda.com>
References: <200309301233.h8UCXcQ21796@candle.pha.pa.us>
	<19140.1064930871@sss.pgh.pa.us>
	<20030930074408.H14474@megazone.bigpanda.com>
	<19584.1064934958@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


On Tue, 30 Sep 2003, Tom Lane wrote:

> Stephan Szabo <sszabo@megazone.bigpanda.com> writes:
> > As a side note, in the partial implementation I'd already done, I noticed
> > a potential problem if the person doing the alter table didn't have read
> > permissions on the pktable. I'd written it to bail and do the slow check
> > in that case (well actually in most error cases that didn't themselves
> > cause an elog), does anyone have a better idea?
>
> Wouldn't all the subsequent triggers fail also in such a case?  (For
> that matter, wouldn't the existing implementation of the initial check
> fail?)  I can't see a reason to expend code to avoid failing here.  It's

No, because the triggers change permissions to the owner of the
appropriate (either fk or pk) table before running the query, so the old
method works as well as the final constraint would. However, if the two
owners are not the same, you can't set to both during the single query.

> not very sensible to be able to create an FK on a table you don't have
> read permission for.

IIRC, you only need references permissions to make an fk constraint, not
select.