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. For most people it's
not a big problem in practice, but actually I think that it's pretty
lame that we have a limit at all. 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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company