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

Поиск
Список
Период
Сортировка
От Adam Brightwell
Тема Re: security labels on databases are bad for dump & restore
Дата
Msg-id CAKRt6CSM+BDtnwOTUfB3TGsQ5krmzpDc2PjsCenWKRB+F-i6cQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: security labels on databases are bad for dump & restore  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: security labels on databases are bad for dump & restore  (Noah Misch <noah@leadboat.com>)
Список pgsql-hackers
>> 1. "pg_dumpall -g"
>> 2. "pg_dump --create" per database
>
> Gah, OK, I see your point.  But we better document this, because if
> you need a PhD in PostgreSQL-ology to take a backup, we're not in a
> good place.

Agreed.  Though, honestly, I find this to be a cumbersome approach.  I
think it just makes things more confusing, even if it is well
documented.  Perhaps it might be necessary as a bridge to get to a
better place.  But my first question as an end user would be, 'why
can't one tool do this?'.  Also, by using 'pg_dumpall -g' aren't you
potentially getting things that you don't want/need/care about?  For
instance, if database 'foo' is owned by 'user1' and database 'bar' is
owned by 'user2' and neither have any knowledge/relation of/to the
other, then when I dump 'foo', in this manner, wouldn't I also be
including 'user2'?  Said differently, a restore of a 'foo'-only dump
would also include a 'bar' related role.  That seems like a bad idea,
IMHO.  Maybe it can't be avoided, but I'd expect that only relevant
information for the database being dumped would be included.

-Adam

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



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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Doubt about AccessExclusiveLock in ALTER TABLE .. SET ( .. );
Следующее
От: Fabrízio de Royes Mello
Дата:
Сообщение: Re: Doubt about AccessExclusiveLock in ALTER TABLE .. SET ( .. );