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
|
Список | 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 по дате отправления: