Re: ADD FOREIGN KEY (was Re: [GENERAL] 7.4Beta)
От | Tom Lane |
---|---|
Тема | Re: ADD FOREIGN KEY (was Re: [GENERAL] 7.4Beta) |
Дата | |
Msg-id | 16054.1064896180@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)
|
Список | pgsql-hackers |
Bruce Momjian <pgman@candle.pha.pa.us> writes: > Jan Wieck wrote: >> Tom Lane wrote: >>> 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. You mean in general, even for plain old insert/update/delete changes? Yipes. What happened to ACID compliance? What I actually expected to ensue was a discussion about how we could narrow down the effects of a disable-foreign-key-verification switch to reduce the odds of shooting oneself in the foot. (For example, maybe disallow it from being set in postgresql.conf.) I wasn't expecting proposals to enlarge the gauge of the foot-gun ... > Also, how does someone turn it on at restore time if they are piping > into psql? Something like export PGOPTIONS="-c disable-fk-verification=true" then run psql or pg_restore. regards, tom lane
В списке pgsql-hackers по дате отправления: