Re: Time to drop old-style (V0) functions?

From: Andres Freund <andres(at)anarazel(dot)de>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Time to drop old-style (V0) functions?
Date: 2016-12-20 13:21:23
Message-ID: 20161220132123.3llbgcwja4pth4cr@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2016-12-20 08:15:07 -0500, Robert Haas wrote:
> On Tue, Dec 20, 2016 at 3:11 AM, Andres Freund <andres(at)anarazel(dot)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.

Andres

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2016-12-20 13:34:19 Re: pg_authid.rolpassword format (was Re: Password identifiers, protocol aging and SCRAM protocol)
Previous Message Andres Freund 2016-12-20 13:19:43 Re: increasing the default WAL segment size