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

From Adam Brightwell
Subject Re: security labels on databases are bad for dump & restore
Date
Msg-id CAKRt6CSZoe8iUYgB2CK+WOrPtuwmTTsYUdZEdObc7UksiMdGyA@mail.gmail.com
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  (Noah Misch <noah@leadboat.com>)
List pgsql-hackers
> Consistency with existing practice would indeed have pg_dump ignore
> pg_shseclabel and have pg_dumpall reproduce its entries.

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 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?

-Adam

-- 
Adam Brightwell - adam.brightwell@crunchydatasolutions.com
Database Engineer - www.crunchydatasolutions.com



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Unnecessary #include in objectaddress.h?
Next
From: Adam Brightwell
Date:
Subject: Re: Unnecessary #include in objectaddress.h?