Re: security labels on databases are bad for dump & restore

Поиск
Список
Период
Сортировка
От Noah Misch
Тема Re: security labels on databases are bad for dump & restore
Дата
Msg-id 20150723060352.GA1388178@tornado.leadboat.com
обсуждение исходный текст
Ответ на Re: security labels on databases are bad for dump & restore  (Adam Brightwell <adam.brightwell@crunchydatasolutions.com>)
Ответы Re: security labels on databases are bad for dump & restore  (Adam Brightwell <adam.brightwell@crunchydatasolutions.com>)
Список pgsql-hackers
On Wed, Jul 22, 2015 at 03:42:58PM -0400, Adam Brightwell wrote:
> > I like Noah's proposal of having pg_dump --create reproduce all
> > database-level state.
> 
> Should it be enabled by default?  If so, then wouldn't it make more
> sense to call it --no-create and do the opposite?  So, --no-create
> would exclude rather than include database-level information?  Would
> enabling it by default cause issues with the current expected use of
> the tool by end users?

While I'd favor optional --no-create if we were designing fresh, it's not
worth breaking user scripts by changing that now.

> How would this handle related global objects? It seems like this part
> could get a little tricky.

Like roles and tablespaces?  No need to change their treatment.

> Taking it one step further, would a --all option that dumps all
> databases make sense as well?  Of course I know that's probably a
> considerable undertaking and certainly beyond the current scope.

I agree it's outside the scope of fixing $subject.

Thanks,
nm



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

Предыдущее
От: Kyotaro HORIGUCHI
Дата:
Сообщение: Re: pg_dump quietly ignore missing tables - is it bug?
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Re: compress method for spgist - 2