From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Variable-length FunctionCallInfoData |
Date: | 2018-12-14 23:03:48 |
Message-ID: | 20181214230348.zisbzqzj35aqbijj@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2018-10-09 12:18:02 -0700, Andres Freund wrote:
> 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?
Any comments? Otherwise I plan to press forward with this soon-ish.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Alexey Bashtanov | 2018-12-14 23:04:26 | log bind parameter values on error |
Previous Message | Michael Paquier | 2018-12-14 23:00:32 | Re: Catalog views failed to show partitioned table information. |