Re: security hook on table creation - Mailing list pgsql-hackers

From Robert Haas
Subject Re: security hook on table creation
Date
Msg-id AANLkTikJU4MgnVa8NLVUhmaQY95rS=ttFyjKvWFrcUwf@mail.gmail.com
Whole thread Raw
In response to Re: security hook on table creation  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses Re: security hook on table creation
List pgsql-hackers
On Wed, Oct 6, 2010 at 5:21 PM, Alvaro Herrera
<alvherre@commandprompt.com> wrote:
> Excerpts from Robert Haas's message of mié oct 06 17:02:22 -0400 2010:
>> 2010/10/5 KaiGai Kohei <kaigai@ak.jp.nec.com>:
>
>> > However, we also have a few headache cases.
>> > DefineType() creates a new type object and its array type, but it does not
>> > call CommandCounterIncrement() by the end of this function, so the new type
>> > entries are not visible from the plugin modules, even if we put a security
>> > hook at tail of the DefineType().
>> > DefineFunction() also has same matter. It create a new procedure object,
>> > but it also does not call CommandCounterIncrement() by the end of this
>> > function, except for the case when ProcedureCreate() invokes language
>> > validator function.
>>
>> So I guess the first question here is why it's important to be able to
>> see the new entry.  I am thinking that you want it so that, for
>> example, you can fetch the namespace OID to perform an SE-Linux type
>> transition.  Is that right?
>
> I'm not sure that there's any point trying to optimize these to the
> point of avoiding CommandCounterIncrement.  Surely DefineType et al are
> not performance-sensitive operations.

OK, fair enough.  Let's just do it unconditionally then.

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


pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: On Scalability
Next
From: Vincenzo Romano
Date:
Subject: Re: On Scalability