Stephan Szabo wrote: > > If we go that direction, why don't we just make a GUC variable to > > disable constraint checking. Is that what this will do, or is it more > > limited. I know it breaks referential integrity, but we have had many > > folks as for it, it is on the TODO list, and there are tons of server > > functions flying around that do just this by fiddling with pg_class. I > > would rather just have it be a GUC for that particular backend. People > > are going to need to turn it off anyway, so why not give them a clean > > way to do it. > > But such a GUC wouldn't affect just one backend. It'd potentially affect > all backends that were doing concurrent modifications that would be > involved since the locks aren't taken. In addition, who would be allowed > to set this value and what constraints would it affect? If it's only > superusers, then it doesn't help for non-superuser restores. If it's > settable by anyone and affects only constraints on tables that user owns > and that refer to tables that user owns it might be okay. If it's > settable by anyone and affects all tables it renders the constraints > meaningless since anyone could break them.
I assume it would be only setable by the super-user. They are mucking around with pg_class anyway (and have permission to do so), so let them do it cleanly at least. Allowing non-supers to do it for tables they own would be OK, I guess. Is there a problem if some of the primary table is owned by someone else? Not sure. -- Bruce Momjian | http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend
