Re: [v9.3] OAT_POST_ALTER object access hooks

Robert Haas <robertmhaas@gmail.com>

From: Robert Haas <robertmhaas@gmail.com>
To: Kohei KaiGai <kaigai@kaigai.gr.jp>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>, PgHacker <pgsql-hackers@postgresql.org>
Date: 2012-12-03T14:03:33Z
Lists: 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