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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
