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

Tom Lane wrote:
> > 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 ...

Fact is, folks are doing it anyway by modifying pg_class. I know one
guy who did it in a transaction so he was the only one to see the
triggers disabled! The PostgreSQL cookbook page has an example too.
People are always asking how to do this. Why not just make it setable
only by the super-user.

FYI, TODO has:

* Allow triggers to be disabled [trigger]
* With disabled triggers, allow pg_dump to use ALTER TABLE ADD FOREIGN
KEY

The second one is the one we are discussing. If we never want to do it,
I will remove it from the TODO list. However, I think we might be
making things too controlled by not allowing administrators to do this.

> > 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.

How many folks are going to remember to do this? Why make it hard for
them? Someone is going to forget too easily. "Why is this restore
taking so long? Oh, I forgot that switch." Or they put it in a login
file and forget it is set. Seems safer for it to be in the dump file.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073