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 по дате отправления: