Re: security labels on databases are bad for dump & restore - Mailing list pgsql-hackers

From Noah Misch
Subject Re: security labels on databases are bad for dump & restore
Date
Msg-id 20150902044333.GA2943548@tornado.leadboat.com
Whole thread Raw
In response to Re: security labels on databases are bad for dump & restore  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
On Mon, Aug 31, 2015 at 05:46:08PM -0400, Bruce Momjian wrote:
> On Tue, Jul 28, 2015 at 04:23:36PM -0300, Alvaro Herrera wrote:
> > Josh Berkus wrote:
> > > On 07/28/2015 11:58 AM, Robert Haas wrote:
> > > > I'd be strongly in favour of teaching GRANT, SECURITY LABEL, COMMENT
> > > >> ON DATABASE, etc to recognise CURRENT_DATABASE as a keyword. Then
> > > >> dumping them in pg_dump --create, and in pg_dump -Fc .
> > > >>
> > > >> In practice I see zero real use of pg_dumpall without --globals-only,
> > > >> and almost everyone does pg_dump -Fc . I'd like to see that method
> > > >> case actually preserve the whole state of the system and do the right
> > > >> thing sensibly.
> > > >>
> > > >> A pg_restore option to skip database-level settings could be useful,
> > > >> but I think by default they should be restored.
> > > 
> > > +++++1
> > > 
> > > Let's get rid of pg_dumpall -g.
> > 
> > Quite the opposite, I think --- let's get rid of pg_dumpall EXCEPT when
> > invoked as pg_dumpall -g.
> 
> Is this a TODO?

Most ideas from this thread had been on TODO for 5+ years.  I've just now
linked the main existing item to this thread.  Removing modes of pg_dumpall
isn't on TODO, but I don't think it has enough support to belong there.

Thanks,
nm



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Horizontal scalability/sharding
Next
From: Jim Nasby
Date:
Subject: Re: Fwd: Core dump with nested CREATE TEMP TABLE