Candidate for local inline function?

From: Kevin Grittner <kgrittn(at)gmail(dot)com>
To: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Candidate for local inline function?
Date: 2017-03-17 20:17:33
Message-ID: CACjxUsNuiXku4=tiN3J-srRNVdS6VPb_-etK0OF3JMhHCbZ-vw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Why do we warn of a hazard here instead of eliminating said hazard
with a static inline function declaration in executor.h?

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

--
Kevin Grittner

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2017-03-17 20:20:49 Re: increasing the default WAL segment size
Previous Message Tom Lane 2017-03-17 20:12:58 Re: pageinspect and hash indexes