Re: ADD FOREIGN KEY (was Re: [GENERAL] 7.4Beta)
От | Jan Wieck |
---|---|
Тема | Re: ADD FOREIGN KEY (was Re: [GENERAL] 7.4Beta) |
Дата | |
Msg-id | 3F78D469.6000205@Yahoo.com обсуждение исходный текст |
Ответ на | Re: ADD FOREIGN KEY (was Re: [GENERAL] 7.4Beta) (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: ADD FOREIGN KEY (was Re: [GENERAL] 7.4Beta)
|
Список | pgsql-hackers |
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. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
В списке pgsql-hackers по дате отправления: