Re: [WIP] ALTER ... OWNER TO ... CASCADE

Поиск
Список
Период
Сортировка
От Teodor Sigaev
Тема Re: [WIP] ALTER ... OWNER TO ... CASCADE
Дата
Msg-id 56C1F513.2040901@sigaev.ru
обсуждение исходный текст
Ответ на Re: [WIP] ALTER ... OWNER TO ... CASCADE  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [WIP] ALTER ... OWNER TO ... CASCADE  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
> TBH, this sounds like a completely terrible idea.  There are far too many
> sorts of dependencies across which one would not expect ownership to
> propagate; for example, use of a function in a view, or even just a
> foreign key dependency between two tables.
>
> I'm not even clear that there are *any* cases where this behavior is
> wanted, other than perhaps ALTER OWNER on an extension --- and even there,
> what you would want is altering the ownership of the member objects, but
> not everything that depends on the member objects.
>
> So basically, a generic CASCADE facility sounds like a lot of work to
> produce something that would seldom be anything but a foot-gun.

DELETE FROM  or TRUNCATE could be a foot-gun too, but it's not a reason to 
remove tham. I faced with problem when I tried to change owner of datadase with 
all objects inside. Think, this feature could be useful although it should 
restricted to superuser obly.

-- 
Teodor Sigaev                                   E-mail: teodor@sigaev.ru
  WWW: http://www.sigaev.ru/
 



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

Предыдущее
От: Dmitry Ivanov
Дата:
Сообщение: Re: [WIP] ALTER ... OWNER TO ... CASCADE
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: Small PATCH: check of 2 Perl modules