Re: [v9.2] SECURITY LABEL on shared database object

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: [v9.2] SECURITY LABEL on shared database object
Дата
Msg-id CA+TgmoZO4Q6xSEhimL+2k2C18-PsZ3-H7fp39DuNdkm3OQNq6w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [v9.2] SECURITY LABEL on shared database object  (Alvaro Herrera <alvherre@commandprompt.com>)
Ответы Re: [v9.2] SECURITY LABEL on shared database object
Список pgsql-hackers
On Tue, Jul 5, 2011 at 10:49 AM, Alvaro Herrera
<alvherre@commandprompt.com> wrote:
> Excerpts from Robert Haas's message of mar jul 05 10:19:18 -0400 2011:
>
>> Hmm, OK.  I guess what I'm not sure about is - how much should we
>> worry about the fact that this creates several more shared (and
>> therefore nailed?) system catalogs?  Anyone have an opinion on that?
>
> "Several"?  That would worry me, given that we currently have a small
> number (eight currently).  If it's just one more, I don't think it's
> such a big deal.  I'm not sure what you mean by nailed though -- I mean,
> for example pg_shdescription is shared but not nailed in the rd_isnailed
> sense of the word, AFAICS.

Well, right now the patch has pg_shseclabel, and its index, plus a
toast table and a toast index.  Not sure why we want/need the toast
table & index there, but the patch has 'em as of now.

As for whether it needs to be nailed, I'm not sure I understand what
the rules are there.  I *think* the rule is that anything that might
need to be consulted before choosing a database must be nailed.  If
that's right, we might be able to get by without nailing it, as long
as the label isn't needed during authentication (or its use can be
postponed until after we've connected to a database).

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


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

Предыдущее
От: Pavel Golub
Дата:
Сообщение: COPY .... WITH (FORMAT binary) causes syntax error at or near "binary"
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: [COMMITTERS] pgsql: Move Trigger and TriggerDesc structs out of rel.h into a new rel