Re: security labels on databases are bad for dump & restore
От | Noah Misch |
---|---|
Тема | Re: security labels on databases are bad for dump & restore |
Дата | |
Msg-id | 20150721060628.GC1339234@tornado.leadboat.com обсуждение исходный текст |
Ответ на | Re: security labels on databases are bad for dump & restore (Adam Brightwell <adam.brightwell@crunchydatasolutions.com>) |
Ответы |
Re: security labels on databases are bad for dump & restore
|
Список | pgsql-hackers |
On Mon, Jul 20, 2015 at 07:01:14PM -0400, Adam Brightwell wrote: > > 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 any given situation, we should indeed restore both pg_database comments and pg_database security labels, or we should restore neither. Restoring neither is most consistent with history, but several people like the idea of restoring both. I won't mind either conclusion. > > 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.
В списке pgsql-hackers по дате отправления: