From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Kevin Grittner <kgrittn(at)gmail(dot)com> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Candidate for local inline function? |
Date: | 2017-04-03 22:34:15 |
Message-ID: | 20170403223415.pnjbaumpf7zmcttb@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2017-03-17 15:29:27 -0500, Kevin Grittner wrote:
> On Fri, Mar 17, 2017 at 3:23 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> > On 2017-03-17 15:17:33 -0500, Kevin Grittner wrote:
> >> Why do we warn of a hazard here instead of eliminating said hazard
> >> with a static inline function declaration in executor.h?
> >
> > Presumably because it was written long before we started relying on
> > inline functions :/
>
> Right. git blame says it was changed in 2004.
>
> >> /*
> >> * ExecEvalExpr was formerly a function containing a switch statement;
> >> * now it's just a macro invoking the function pointed to by an ExprState
> >> * node. Beware of double evaluation of the ExprState argument!
> >> */
> >> #define ExecEvalExpr(expr, econtext, isNull) \
> >> ((*(expr)->evalfunc) (expr, econtext, isNull))
> >>
> >> Should I change that to a static inline function doing exactly what
> >> the macro does? In the absence of multiple evaluations of a
> >> parameter with side effects, modern versions of gcc have generated
> >> the same code for a macro versus a static inline function, at least
> >> in the cases I checked.
> >
> > I'm absolutely not against changing this to an inline function, but I'd
> > prefer if that code weren't touched quite right now, there's a large
> > pending patch of mine in the area. If you don't mind, I'll just include
> > the change there, rather than have a conflict?
>
> Fine with me.
For posterities sake: I've indeed done so.
- Andres
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2017-04-03 22:38:59 | Re: Rewriting the test of pg_upgrade as a TAP test |
Previous Message | Michael Paquier | 2017-04-03 22:28:47 | Re: Rewriting the test of pg_upgrade as a TAP test |