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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: ADD FOREIGN KEY (was Re: [GENERAL] 7.4Beta)
Дата
Msg-id 13819.1064882905@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: ADD FOREIGN KEY (was Re: [GENERAL] 7.4Beta)  (Jan Wieck <JanWieck@Yahoo.com>)
Ответы Re: ADD FOREIGN KEY (was Re: [GENERAL] 7.4Beta)  (Jan Wieck <JanWieck@Yahoo.com>)
Список pgsql-hackers
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.

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.
        regards, tom lane


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

Предыдущее
От: Stephan Szabo
Дата:
Сообщение: Re: ADD FOREIGN KEY (was Re: [GENERAL] 7.4Beta)
Следующее
От: Tom Lane
Дата:
Сообщение: Re: ERROR: "foo_type" is a composite type