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

Noah Misch 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.

Agreed, and IMO it's embarrasing that it's so complicated to get a fully
working backup.

> I much prefer making this work completely:
> 
> 1. "pg_dumpall -g"
> 2. "pg_dump --create" per database

My full support for this proposal.

> Another formula I wouldn't mind offering:
> 
> 1. "pg_dumpall -g"
> 2. pg_dumpall --empty-databases
> 3. "pg_dump" (without --create) per database
> 
> Code for an --empty-databases option already exists for "pg_dumpall -g
> --binary-upgrade".  A patch turning that into a user-facing feature might be
> quite compact.

I don't mind if this one is also made to work, but I don't care about
this case all that much.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services