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

Поиск
Список
Период
Сортировка
От Stephan Szabo
Тема Re: ADD FOREIGN KEY (was Re: [GENERAL] 7.4Beta)
Дата
Msg-id 20030930074408.H14474@megazone.bigpanda.com
обсуждение исходный текст
Ответ на 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)  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: ADD FOREIGN KEY (was Re: [GENERAL] 7.4Beta)  (Jan Wieck <JanWieck@Yahoo.com>)
Список 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 по дате отправления:

Предыдущее
От: Robert Treat
Дата:
Сообщение: Re: expanding on syslog help
Следующее
От: Tom Lane
Дата:
Сообщение: Re: ADD FOREIGN KEY (was Re: [GENERAL] 7.4Beta)