Re: security labels on databases are bad for dump & restore

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: security labels on databases are bad for dump & restore
Дата
Msg-id CA+TgmoYnLHjL-hL+j1_rfCosnM=kGJVtO4UifM0D6U_UPOR0HQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: security labels on databases are bad for dump & restore  (Andres Freund <andres@anarazel.de>)
Ответы Re: security labels on databases are bad for dump & restore  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
On Tue, Jul 28, 2015 at 3:03 PM, Andres Freund <andres@anarazel.de> wrote:
> On 2015-07-28 14:58:26 -0400, Robert Haas wrote:
>> Yes, I think we should make restoring the database's properties the
>> job of pg_dump and remove it completely from pg_dumpall, unless we can
>> find a case where that's really going to break things.
>
> CREATE DATABASE blarg;
> SECURITY LABEL ON blarg IS 'noaccess';
> ALTER DATABASE blarg SET default_tablespace = space_with_storage;
> pg_restore
> -> SECURITY LABEL ON blarg IS 'allow_access';
> -> ALTER DATABASE blarg SET default_tablespace = space_without_storage;
>
> That's probably not sufficient reasons not to go that way, but I do
> think there's a bunch more issues like that.

Could you use some complete sentences to describe what the actual
issue is?  I can't make heads or tails of what you wrote there.

> At the very least all these need to be emitted as ALTER DATABASE
> current_database ... et al. Otherwise it's impossible to rename
> databases, which definitely would not be ok.

Yep, I think that's the plan.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: security labels on databases are bad for dump & restore
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: Planner debug views