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+TgmobD-XgYTbzDvR+Z6WBXA01wXoAw7Tf8a5C9_RrtCO9Bmw@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
|
Список | pgsql-hackers |
On Thu, Jul 30, 2015 at 2:49 AM, Noah Misch <noah@leadboat.com> wrote: > What exact formula did you have in mind? It must not be merely > > 1. "pg_dumpall -g" > 2. "pg_dump" (without --create) per database > > which _never_ works: it emits no CREATE DATABASE statements. Perhaps this? > > 1. "pg_dumpall -g" > 2. Issue a handwritten CREATE DATABASE statement per database with correct > encoding, lc_ctype and lc_collate parameters. All other database > properties can be wrong; the dump will fix them. > 3. "pg_dump" (without --create) per database > > That neglects numerous database properties today, but we could make it work. > Given the problems I described upthread, it's an inferior formula that I > recommend against propping up. I much prefer making this work completely: > > 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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: