Re: [v9.3] OAT_POST_ALTER object access hooks
От | Robert Haas |
---|---|
Тема | Re: [v9.3] OAT_POST_ALTER object access hooks |
Дата | |
Msg-id | CA+TgmobX0D=eAoU2GxRvK5f71VAuJXfquhJK6biaozzXofnT6Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [v9.3] OAT_POST_ALTER object access hooks (Kohei KaiGai <kaigai@kaigai.gr.jp>) |
Ответы |
Re: [v9.3] OAT_POST_ALTER object access hooks
|
Список | pgsql-hackers |
On Tue, Nov 20, 2012 at 8:43 AM, Kohei KaiGai <kaigai@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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: