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

On Wed, Jul 15, 2015 at 11:08:53AM +0200, Andres Freund wrote:
> On 2015-07-15 12:04:40 +0300, Alvaro Herrera wrote:
> > Andres Freund wrote:
> > > One thing worth mentioning is that arguably the problem is caused by the
> > > fact that we're here emitting database level information in pg_dump,
> > > normally only done for dumpall.

Consistency with existing practice would indeed have pg_dump ignore
pg_shseclabel and have pg_dumpall reproduce its entries.

> > ... the reason for which is probably the lack of CURRENT_DATABASE as a
> > database specifier. It might make sense to add the rest of
> > database-level information to pg_dump output, when we get that.
>
> I'm not sure. I mean, it's not that an odd idea to assign a label to a
> database and then restore data into it, and expect the explicitly
> assigned label to survive. Not sure if there actually is a good
> behaviour either way here :/

In a greenfield, I would make "pg_dump --create" reproduce pertinent entries
from datacl, pg_db_role_setting, pg_shseclabel and pg_shdescription. I would
make non-creating pg_dump reproduce none of those. Moreover, I would enable
--create by default. Restoring into a user-provided shell database is
specialized compared to reproducing a database from scratch.