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

Поиск
Список
Период
Сортировка
От Adam Brightwell
Тема Re: security labels on databases are bad for dump & restore
Дата
Msg-id CAKRt6CSZoe8iUYgB2CK+WOrPtuwmTTsYUdZEdObc7UksiMdGyA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: security labels on databases are bad for dump & restore  (Noah Misch <noah@leadboat.com>)
Ответы Re: security labels on databases are bad for dump & restore  (Noah Misch <noah@leadboat.com>)
Список pgsql-hackers
> Consistency with existing practice would indeed have pg_dump ignore
> pg_shseclabel and have pg_dumpall reproduce its entries.

I think that makes sense, but what about other DATABASE level info
such as COMMENT?  Should that also be ignored by pg_dump as well?  I'm
specifically thinking of the discussion from the following thread:

http://www.postgresql.org/message-id/20150317172459.GM3636@alvh.no-ip.org

If COMMENT is included then why not SECURITY LABEL or others?

> In a greenfield, I would make "pg_dump --create" reproduce pertinent entries
> from datacl, pg_db_role_setting, pg_shseclabel and pg_shdescription.  I would
> make non-creating pg_dump reproduce none of those.

I think the bigger question is "Where is the line drawn between
pg_dump and pg_dumpall?".  At what point does one tool become the
other?

-Adam

-- 
Adam Brightwell - adam.brightwell@crunchydatasolutions.com
Database Engineer - www.crunchydatasolutions.com



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

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: Unnecessary #include in objectaddress.h?
Следующее
От: Adam Brightwell
Дата:
Сообщение: Re: Unnecessary #include in objectaddress.h?