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

From Alvaro Herrera
Subject Re: security labels on databases are bad for dump & restore
Date
Msg-id 20150721070820.GA5596@postgresql.org
Whole thread Raw
In response to Re: security labels on databases are bad for dump & restore  (Noah Misch <noah@leadboat.com>)
Responses Re: security labels on databases are bad for dump & restore
List pgsql-hackers
Noah Misch wrote:
> On Mon, Jul 20, 2015 at 07:01:14PM -0400, Adam Brightwell wrote:

> > I think that makes sense, but what about other DATABASE level info
> > such as COMMENT?  Should that also be ignored by pg_dump as well?  I'm
> > specifically thinking of the discussion from the following thread:
> > 
> > http://www.postgresql.org/message-id/20150317172459.GM3636@alvh.no-ip.org
> > 
> > If COMMENT is included then why not SECURITY LABEL or others?
> 
> In any given situation, we should indeed restore both pg_database comments and
> pg_database security labels, or we should restore neither.

Agreed.

> > > 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.
> > 
> > I think the bigger question is "Where is the line drawn between
> > pg_dump and pg_dumpall?".  At what point does one tool become the
> > other?
> 
> That question may be too big for me.

I don't think there's any line near pg_dumpall.  That tool seems to
have grown out of desperation without much actual design.  I think it
makes more sense to plan around that's the best pg_dump behavior for the
various use cases.

I like Noah's proposal of having pg_dump --create reproduce all
database-level state.

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



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Support for N synchronous standby servers - take 2
Next
From: Pavel Stehule
Date:
Subject: Re: PL/pgSQL, RAISE and error context