(2010/11/10 13:06), Robert Haas wrote:
>> In this patch, we put InvokeObjectAccessHook0 on the following functions.
>>
>> - heap_create_with_catalog() for relations/attributes
>> - ATExecAddColumn() for attributes
>> - NamespaceCreate() for schemas
>> - ProcedureCreate() for aggregates/functions
>> - TypeCreate() and TypeShellMake() for types
>> - create_proc_lang() for procedural languages
>> - inv_create() for large objects
>
> I think you ought to try to arrange to avoid the overhead of a
> function call in the common case where nobody's using the hook.
> That's why I originally suggested making InvokeObjectAccessHook() a
> macro around the actual function call.
>
Hmm. Although I have little preference here, the penalty to call
an empty function (when no plugins are installed) is not visible,
because frequency of DDL commands are not high.
Even so, is it necessary to replace them by macros?
> I don't want to refer to this as a framework for enhanced security
> providers. Let's stick with the term "object access hook". Calling
> it an enhanced security provider overspecifies; it could equally well
> be used for, say, logging.
>
OK. As Itagaki-san also pointed out, we may be able to utilize the hooks
in other purposes. Although I designed it in similar manner with security
label provider, I'll revise it like as other hooks doing.
> Is there any compelling reason not to apply this to every object type
> in the system (e.g. all the ones COMMENT can apply to)? I don't see
> any reason to restrict it to the set of objects to which it's sensible
> to apply security labels.
>
Because I thought too many hooks within one patch gives burden to reviewers,
so I restricted it on a part of object classes in this version.
However,it is not a compelling reason.
OK, I'll try to revise the patch soon.
Thanks,
--
KaiGai Kohei <kaigai@kaigai.gr.jp>
