Re: Label switcher function

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>
Cc: KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Label switcher function
Date: 2010-12-06 19:38:22
Message-ID: AANLkTimex+C78vaPZm71QsCmfwX9kgycqb-eN0HqOHdE@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2010/11/25 KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>:
> The attached patch is a revised one.
>
> It provides two hooks; the one informs core PG whether the supplied
> function needs to be hooked, or not. the other is an actual hook on
> prepare, start, end and abort of function invocations.
>
>  typedef bool (*needs_function_call_type)(Oid fn_oid);
>
>  typedef void (*function_call_type)(FunctionCallEventType event,
>                                     FmgrInfo *flinfo, Datum *private);
>
> The hook prototype was a bit modified since the suggestion from
> Robert. Because FmgrInfo structure contain OID of the function,
> it might be redundant to deliver OID of the function individually.
>
> Rest of parts are revised according to the comment.
>
> I also fixed up source code comments which might become incorrect.

FCET_PREPARE looks completely unnecessary to me. Any necessary
one-time work can easily be done at FCET_START time, assuming that the
private-data field is initialized to (Datum) 0.

I'm fairly certain that the following is not portable:

+ ObjectAddress object = { .classId = ProcedureRelationId,
+ .objectId = fn_oid,
+ .objectSubId = 0 };

I'd suggest renaming needs_function_call_type and function_call_type
to needs_fmgr_hook_type and fmgr_hook_type.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Berkus 2010-12-06 19:47:00 Re: profiling connection overhead
Previous Message David E. Wheeler 2010-12-06 19:36:30 Re: Per-column collation