Re: Candidate for local inline function?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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:29:53
Message-ID: 29050.1489782593@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Kevin Grittner <kgrittn(at)gmail(dot)com> writes:
> 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?

No, because that code has only days to live anyway. You'd just
create a merge hazard for Andres' execQual rewrite.

In practice, I seriously doubt that there are or ever will be any
callers passing volatile expressions to this macro, so that there's
not really much advantage to be gained by assuming that the compiler
is smart about inline functions.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2017-03-17 20:44:47 Re: new set of psql patches for loading (saving) data from (to) text, binary files
Previous Message Kevin Grittner 2017-03-17 20:29:27 Re: Candidate for local inline function?