Re: ADD FOREIGN KEY (was Re: [GENERAL] 7.4Beta) - Mailing list pgsql-hackers

From Stephan Szabo
Subject Re: ADD FOREIGN KEY (was Re: [GENERAL] 7.4Beta)
Date
Msg-id 20030930074408.H14474@megazone.bigpanda.com
Whole thread Raw
In response to Re: ADD FOREIGN KEY (was Re: [GENERAL] 7.4Beta)  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: ADD FOREIGN KEY (was Re: [GENERAL] 7.4Beta)
Re: ADD FOREIGN KEY (was Re: [GENERAL] 7.4Beta)
List pgsql-hackers
On Tue, 30 Sep 2003, Tom Lane wrote:

> I see where Stephan is coming from, but in my mind disabling consistency
> checks ought to be a feature reserved to the DBA (ie superuser), who
> presumably has some clue about the tradeoffs involved.  I don't think
> ordinary users should be able to do it.  If we can get the cost of
> performing the initial check down to something reasonable (and I don't
> mean "near zero", I mean something that's small in comparison to the
> other costs of loading data and creating indexes), then I think we've
> done as much as we should do for ordinary users.

Limiting the cases under which constraint ignoring works is certainly
fine by me, but I was assuming that we were trying to make it accessable
to any restore. If that's not true, then we don't need to worry about that
part of the issue.

As a side note, in the partial implementation I'd already done, I noticed
a potential problem if the person doing the alter table didn't have read
permissions on the pktable. I'd written it to bail and do the slow check
in that case (well actually in most error cases that didn't themselves
cause an elog), does anyone have a better idea?


pgsql-hackers by date:

Previous
From: Robert Treat
Date:
Subject: Re: expanding on syslog help
Next
From: Tom Lane
Date:
Subject: Re: ADD FOREIGN KEY (was Re: [GENERAL] 7.4Beta)