Re: Variable-length FunctionCallInfoData - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Variable-length FunctionCallInfoData
Date
Msg-id 20181009191802.ppt6lqcvkpjvkm76@alap3.anarazel.de
Whole thread Raw
In response to Variable-length FunctionCallInfoData  (Andres Freund <andres@anarazel.de>)
Responses Re: Variable-length FunctionCallInfoData  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
Hi,

Here's an updated version of the patch. Besides a rebase the biggest
change is that I've wrapped:

On 2018-06-05 10:29:52 -0700, Andres Freund wrote:
> There's some added uglyness, which I hope we can polish a bit
> further. Right now we allocate a good number of FunctionCallInfoData
> struct on the stack - which doesn't quite work afterwards anymore.  So
> the stack allocations, for the majoroity cases where the argument number
> is known, currently looks like:
> 
>     union {
>         FunctionCallInfoData fcinfo;
>         char *fcinfo_data[SizeForFunctionCallInfoData(0)];
>     } fcinfodata;
>     FunctionCallInfo fcinfo = &fcinfodata.fcinfo;
> 
> that's not pretty, but also not that bad.

into a macro STACK_FCINFO_FOR_ARGS(varname, numargs). That makes the
code look much nicer.

I think we should go for this. If there's some agreement on that I'll
perform a bit more polishing.

I think it'd probably good to add accessors for value/nullness in
arguments that hide the difference between <v12 and v12, for the sake of
extension authors. Would probably mostly make sense if we backpatched
those for compatibility.


Also attached is a second patch that avoids all the duplication in
fmgr.[ch]. While the savings are nice, I'm a bit doubtful that the
amount of magic here is reasonable.  Any opinions?

Greetings,

Andres Freund

Attachment

pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: pread() and pwrite()
Next
From: Andres Freund
Date:
Subject: [HACKERS] removing abstime, reltime, tinterval.c, spi/timetravel