Re: security hooks on object creation - Mailing list pgsql-hackers

From Robert Haas
Subject Re: security hooks on object creation
Date
Msg-id AANLkTinW_gkT+a6L7osXLrsduK7U_a2G0VipwXvOD5yy@mail.gmail.com
Whole thread Raw
In response to Re: security hooks on object creation  (KaiGai Kohei <kaigai@kaigai.gr.jp>)
Responses Re: security hooks on object creation
List pgsql-hackers
On Wed, Nov 10, 2010 at 8:33 AM, KaiGai Kohei <kaigai@kaigai.gr.jp> wrote:
> (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?

It's a fair point.  I'm open to other opinions but my vote is to shove
a macro in there.  A pointer test is cheaper than a function call, and
doesn't really complicate things much.

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


pgsql-hackers by date:

Previous
From: "David E. Wheeler"
Date:
Subject: Re: multi-platform, multi-locale regression tests
Next
From: Andrew Dunstan
Date:
Subject: Re: improved parallel make support