Re: [HACKERS] Time to drop old-style (V0) functions? - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [HACKERS] Time to drop old-style (V0) functions?
Date
Msg-id CA+TgmobAFeMhmH63+o8Waek3t0dNDpg5cyPaT3F42jZ9aiK=5w@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Time to drop old-style (V0) functions?  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Responses Re: [HACKERS] Time to drop old-style (V0) functions?  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On Mon, Dec 19, 2016 at 3:13 PM, Peter Eisentraut
<peter.eisentraut@2ndquadrant.com> wrote:
> On 12/9/16 7:52 AM, Robert Haas wrote:
>> It's kind of ironic, at least IMHO, that the DirectionFunctionCall
>> macros are anything but direct.  Each one is a non-inlined function
>> call that does a minimum of 8 variable assignments before actually
>> calling the function.
>
> If this is a problem (it might be), then we can just make those calls,
> er, direct C function calls to different function.  For example,
>
>     result = DatumGetObjectId(DirectFunctionCall1(oidin,
>                               CStringGetDatum(pro_name_or_oid)));
>
> could just be
>
>     result = oidin_internal(pro_name_or_oid);

Yeah, true -- that works for simple cases, and might be beneficial
where you're doing lots and lots of calls in a tight loop.

For the more general problem, I wonder if we should try to figure out
something where we have one calling convention for "simple" functions
(those that little or none of the information in fcinfo and can pretty
much just take their SQL args as C args) and another for "complex"
functions (where we do the full push-ups).

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



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: [HACKERS] Time to drop old-style (V0) functions?
Next
From: Peter Eisentraut
Date:
Subject: Re: [HACKERS] Proposal for changes to recovery.conf API