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
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 |