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)  (Bruce Momjian <pgman@candle.pha.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Christopher Kings-Lynne
Дата:
Сообщение: signal to send to postgres when log rolling
Следующее
От: Stephan Szabo
Дата:
Сообщение: Re: ADD FOREIGN KEY (was Re: [GENERAL] 7.4Beta)