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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: ADD FOREIGN KEY (was Re: [GENERAL] 7.4Beta)
Дата
Msg-id 16307.1064898373@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: ADD FOREIGN KEY (was Re: [GENERAL] 7.4Beta)  (Bruce Momjian <pgman@candle.pha.pa.us>)
Ответы Re: ADD FOREIGN KEY (was Re: [GENERAL] 7.4Beta)  (Bruce Momjian <pgman@candle.pha.pa.us>)
Список pgsql-hackers
Bruce Momjian <pgman@candle.pha.pa.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.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: ADD FOREIGN KEY (was Re: [GENERAL] 7.4Beta)
Следующее
От: Tom Lane
Дата:
Сообщение: Re: ADD FOREIGN KEY (was Re: [GENERAL] 7.4Beta)