Jan Wieck wrote:
>
>
> Tom Lane wrote:
>
> > Jan Wieck <JanWieck@Yahoo.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.
Also, how does someone turn it on at restore time if they are piping
into psql?
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square,
Pennsylvania19073