Re: Candidate for local inline function?

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-03-17 20:23:35
Message-ID: 20170317202335.u45looqttlaaqmgk@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Kevin,

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

> /*
> * 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?

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kevin Grittner 2017-03-17 20:29:27 Re: Candidate for local inline function?
Previous Message Peter Eisentraut 2017-03-17 20:20:49 Re: increasing the default WAL segment size