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

Поиск
Список
Период
Сортировка
От Jan Wieck
Тема Re: ADD FOREIGN KEY (was Re: [GENERAL] 7.4Beta)
Дата
Msg-id 3F79CE69.3040203@Yahoo.com
обсуждение исходный текст
Ответ на Re: ADD FOREIGN KEY (was Re: [GENERAL] 7.4Beta)  (Stephan Szabo <sszabo@megazone.bigpanda.com>)
Ответы Re: ADD FOREIGN KEY (was Re: [GENERAL] 7.4Beta)  (Bruce Momjian <pgman@candle.pha.pa.us>)
Список pgsql-hackers
Stephan Szabo wrote:

> On Tue, 30 Sep 2003, Jan Wieck wrote:
> 
>> Stephan Szabo wrote:
>> > 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.
>>
>> It is not true.
>>
>> Fact is that restoring can require more rights than creating the dump.
>> That is already the case if you want to restore anything that contains
>> objects owned by different users. Trying to enable everyone who can take
>> a dump also to restore it, by whatever mechanism, gives someone the
>> right to revert things in time and create a situation (consistent or
>> not) that he could not (re)create without doing dump/restore. This is
>> wrong and should not be possible.
> 
> I think this is a larger argument than the one that was being discussed
> above. Given a dump of objects I own, can I restore them without requiring
> the fk check to be done if I alter table add constraint a foreign key? If
> the answer to that is no, then the option can be put in as a superuser
> only option and it's relatively easy. If the answer to that is yes, then
> there are additional issues that need to be resolved.

Well, with the CREATE CONSTRAINT TRIGGER you _can_, but we already have 
a consensus that we don't _want_ that. Probably we should declare it 
deprecated and remove it in 7.5. And the option currently under 
discussion is exactly what will cause ALTER TABLE to let you, but IMHO 
that _should_ be restricted.


Jan

-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andreas Pflug
Дата:
Сообщение: Re: GPL code issue?
Следующее
От: Tom Lane
Дата:
Сообщение: Re: invalid tid errors in latest 7.3.4 stable.