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

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: security labels on databases are bad for dump & restore
Дата
Msg-id CA+TgmoYci5bLCb++eHuo9xYxwVyJva8ZMmNRfeEKJ1YZstTdCA@mail.gmail.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  (Noah Misch <noah@leadboat.com>)
Список pgsql-hackers
On Wed, Jul 22, 2015 at 3:42 PM, Adam Brightwell
<adam.brightwell@crunchydatasolutions.com> wrote:
>> I don't think there's any line near pg_dumpall.  That tool seems to
>> have grown out of desperation without much actual design.  I think it
>> makes more sense to plan around that's the best pg_dump behavior for the
>> various use cases.
>
> Ok.
>
>> 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?

This seems a bit hairy to me.  If we want to transfer responsibility
for dumping this stuff from pg_dumpall to pg_dump, I have no problem
with that at all.  But doing it only when --create is specified seems
odd.  Then, does pg_dumpall -g dump it or not?  If it does, then we're
sorta dumping it in two places when --create is used.  If it doesn't,
then when --create is not used we're doing it nowhere.

I may be confused.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



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

Предыдущее
От: Adam Brightwell
Дата:
Сообщение: Re: security labels on databases are bad for dump & restore
Следующее
От: Fabien COELHO
Дата:
Сообщение: Re: pgbench stats per script & other stuff