Re: ADD FOREIGN KEY (was Re: [GENERAL] 7.4Beta)

On Tue, 30 Sep 2003, Bruce Momjian wrote:

> Jan Wieck wrote:
> >
> >
> > Tom Lane wrote:
> >
> > > Jan Wieck <JanWieck(at)Yahoo(dot)com> writes:
> > >> I think I can accept it to be the choice of the DBA what to do. Pg_dump
> > >> has that kind of options already, one can choose between COPY and INSERT
> > >> for example. Why not adding the choice of dumping FKeys as ALTER TABLE
> > >> or CREATE CONSTRAINT TRIGGER?
> > >
> > > We don't want it dumping as CREATE CONSTRAINT TRIGGER, because (a) that
> > > loses pg_depend information and (b) it's too low-level a representation;
> > > we couldn't ever change the implementation of foreign keys as long as
> > > dumps look like that.
> >
> > That's finally 2 points, okay.
> >
> > >
> > > Also, I don't see why you'd want to make such a choice at pg_dump time.
> > > Probably better to control it at restore time. Accordingly, my proposal
> > > if we were to go that route would be a boolean GUC variable that simply
> > > prevents ALTER TABLE ADD FOREIGN KEY from doing the validity checks.
> >
> > Okay too. And this would be simple and safe enough to add it at the time
> > being.
>
> 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.