Date: Mon, 29 Sep 2003 22:52:35 -0700 (PDT)
From: Stephan Szabo <sszabo@megazone.bigpanda.com>
To: Bruce Momjian <pgman@candle.pha.pa.us>
Cc: Jan Wieck <JanWieck@Yahoo.com>, Tom Lane <tgl@sss.pgh.pa.us>,
	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: <200309300455.h8U4t0Y18905@candle.pha.pa.us>
Message-ID: <20030929224831.C7993@megazone.bigpanda.com>
References: <200309300455.h8U4t0Y18905@candle.pha.pa.us>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Tue, 30 Sep 2003, Bruce Momjian wrote:

> Stephan Szabo wrote:
> > > If we go that direction, why don't we just make a GUC variable to
> > > disable constraint checking.  Is that what this will do, or is it more
> > > limited.  I know it breaks referential integrity, but we have had many
> > > folks as for it, it is on the TODO list, and there are tons of server
> > > functions flying around that do just this by fiddling with pg_class.  I
> > > would rather just have it be a GUC for that particular backend.  People
> > > are going to need to turn it off anyway, so why not give them a clean
> > > way to do it.
> >
> > But such a GUC wouldn't affect just one backend.  It'd potentially affect
> > all backends that were doing concurrent modifications that would be
> > involved since the locks aren't taken.  In addition, who would be allowed
> > to set this value and what constraints would it affect? If it's only
> > superusers, then it doesn't help for non-superuser restores.  If it's
> > settable by anyone and affects only constraints on tables that user owns
> > and that refer to tables that user owns it might be okay.  If it's
> > settable by anyone and affects all tables it renders the constraints
> > meaningless since anyone could break them.
>
> I assume it would be only setable by the super-user.  They are mucking
> around with pg_class anyway (and have permission to do so), so let them
> do it cleanly at least.  Allowing non-supers to do it for tables they
> own would be OK, I guess.  Is there a problem if some of the primary
> table is owned by someone else?  Not sure.

The problem I have with a super-user only solution is that it doesn't
solve the problem for restores in general.  I think we need a mechanism
that works for any user that wants to restore a table (or tables) from
dump(s), so for the dump/restore mechanism I think we should be looking in
that direction.