Re: security labels on databases are bad for dump & restore
От | Alvaro Herrera |
---|---|
Тема | Re: security labels on databases are bad for dump & restore |
Дата | |
Msg-id | 20150721070820.GA5596@postgresql.org обсуждение исходный текст |
Ответ на | Re: security labels on databases are bad for dump & restore (Noah Misch <noah@leadboat.com>) |
Ответы |
Re: security labels on databases are bad for dump & restore
|
Список | 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 по дате отправления: