Re: security hook on table creation

(2010/10/07 6:21), Alvaro Herrera wrote:
> Excerpts from Robert Haas's message of mié oct 06 17:02:22 -0400 2010:
>> 2010/10/5 KaiGai Kohei<kaigai(at)ak(dot)jp(dot)nec(dot)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.
>
Performance optimization is not the point here.

If we need to call CommandCounterIncrement() before invocation of security
hooks, we also need to analyze its side-effect and to confirm it is harmless.
Even if it is harmless, I think it gives us more burden of code maintenance
than the idea of two hooks on creation.

>> Maybe we need a variant of InvokeObjectAccessHook that does a CCI only
>> if a hook is present.
>
> The problem I see with this idea is that it becomes a lot harder to
> track down whether it ocurred or not for any given operation.
>
Yes, it is a burden of code maintenance.

Thanks,
--
KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>