On 2016-12-20 08:35:05 -0500, Robert Haas wrote:
> On Tue, Dec 20, 2016 at 8:21 AM, Andres Freund <andres@anarazel.de> wrote:
> > On 2016-12-20 08:15:07 -0500, Robert Haas wrote:
> >> On Tue, Dec 20, 2016 at 3:11 AM, Andres Freund <andres@anarazel.de> wrote:
> >> > I think a more efficient variant would make the function signature look
> >> > something like:
> >> >
> >> > Datum /* directly returned argument */
> >> > pgfunc(
> >> > /* extra information about function call */
> >> > FunctionCallInfo *fcinfo,
> >> > /* bitmap of NULL arguments */
> >> > uint64_t nulls,
> >> > /* first argument */
> >> > Datum arg0,
> >> > /* second argument */
> >> > Datum arg1,
> >> > /* returned NULL */
> >> > bool *isnull
> >> > );
> >>
> >> Yeah, that's kind of nice. I like the uint64 for nulls, although
> >> FUNC_MAX_ARGS > 64 by default and certainly can be configured that
> >> way. It wouldn't be a problem for any common cases, of course.
> >
> > Well, I suspect we'd have to change that then. Is anybody seriously
> > interested in supporting FUNC_MAX_ARGS > 64? We don't have to make our
> > life hard by supporting useless features... I'd even question using
> > 64bit for this on 32bit platforms.
>
> Advanced Server uses 256, and we had a customer complain recently that
> 256 wasn't high enough. So apparently the use case for functions with
> ridiculous numbers of arguments isn't exactly 0.
Well, there's a cost/benefit analysis involved here, as in a lot of
other places. There's a lot of things one can conceive a use-case for,
doesn't mean it's worth catering for all of them.
> I mean, there's no reason that we can't use dynamic allocation here.
> If we put the first, say, 8 arguments in the FunctionCallInfoData
> itself and then separately allocated space any extras, the structure
> could be a lot smaller without needing an arbitrary limit on the
> argument count.
Except that that'll mean additional overhead during evaluation of
function arguments, an overhead that everyone will have to pay. Suddenly
you need two loops that fill in arguments, depending on their
argument-number (i.e. additional branches in a thight spot). And not
being able to pass the null bitmap via an register argument also costs
everyone.
Andres