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

Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > How many folks are going to remember to do this? Why make it hard for
> > them? Someone is going to forget too easily. "Why is this restore
> > taking so long? Oh, I forgot that switch." Or they put it in a login
> > file and forget it is set. Seems safer for it to be in the dump file.
>
> I disagree. The "how many folks are going to remember to do this"
> argument applies just as well to magic pg_dump switches; that's not
> a tenable argument against doing it at restore time.
>
> The difference between controlling it at pg_dump time and pg_restore
> time is that if you change your mind after having made the dump, it's
> too late, if the decision was nailed down in the dump file. In an
> upgrade situation it's very likely that you no longer have the option
> to re-do your dump, because you already blew away your old installation.
>
> Since there's no performance difference at pg_dump time, I can't see any
> advantage to freezing your decision then.

I understand, and if everyone used pg_restore, then adding a flag to
pg_restore to do this would make sense. However, everyone is used to
treating that dump file as a simple dump and throwing it into psql.
Psql doesn't have any special dump flags, so you have to do the
environment variable trick, which you must admit is pretty ugly looking
and prone to typing errors, and forgetting, because they are used to
invoking psql all the time.

Maybe we need a psql dump reload flag? Would we be able to do any other
optimizations, like increasing sort_mem or something? That would be a
clean solution, and perhaps allow additional optimizations.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073