2012/12/3 Robert Haas <robertmh...@gmail.com>:
> On Tue, Nov 20, 2012 at 8:43 AM, Kohei KaiGai <kai...@kaigai.gr.jp> wrote:
>> I'd like to have catalog/objectaccess.c to wrap-up invocation of hooks,
>> rather
>> than doing all the stuffs with macros. It allows to use local variables,
>> unlike
>> macros; that has a risk of naming conflict with temporary variable for
>> ObjectAccessPostCreate.
>>
>> So, how about to have a following definition for example?
>>
>> void
>> InvokePostAlterHookArgs(Oid classId, Oid objectId, int subId,
>> Oid auxiliaryId, bool is_internal)
>> {
>> if (object_access_hook)
>> {
>> ObjectAccessPostAlter pa_arg;
>>
>> memset(&pa_arg, 0, sizeof(ObjectAccessPostAlter));
>> pa_arg.auxiliary_id = auxiliary_id;
>> pa_arg.is_internal = is_internal;
>> (*object_access_hook)(OAT_POST_ALTER,
>> classId, objectId, subId,
>> (void *) &pa_arg);
>> }
>> }
>>
>> and
>>
>> #define InvokePostAlterHook(classId, objectId, subId) \
>> InvokePostAlterHookArgs(classId, objectId, subId, InvalidOid, false)
>>
>> for most points to call.
>
> This has the disadvantage of incurring the overhead of a function call
> even if (as will typically be the case) there is no object access
> hook. I still prefer having the if (object_access_hook) test in the
> macro, though of course I have no problem with having the macro call
> a function if it's set.
>
OK, I'll adjust the macro definitions to reduce empty function calls.
Thanks,
--
KaiGai Kohei <kai...@kaigai.gr.jp>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
