On 2017-02-14 17:58:23 -0500, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > On 2016-11-26 08:41:28 -0800, Andres Freund wrote:
> >> On November 26, 2016 8:06:26 AM PST, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >>> Those don't call functions, they call operators. Yes, I know that an
> >>> operator has a function underlying it, but the user-level expectation
> >>> for track_functions is that what it counts are things that look
> >>> syntactically like function calls. I'm not eager to add tracking
> >>> overhead for cases that there's been exactly zero field demand for.
>
> >> But we do track for OpExprs? Otherwise I'd agree.
>
> > Bump?
>
> If you're going to insist on foolish consistency, I'd rather take out
> tracking in OpExpr than add it in dozens of other places.
I'm ok with being inconsistent, but I'd like to make that a conscious
choice rather it being the consequence of an oversight - and that's what
it looks like to me.
We're doing it for OpExpr, but not for a bunch of other function /
operator invocations within execQual.c (namely ExecEvalDistinct,
ExecEvalScalarArrayOp, ExecEvalRowCompare, ExecEvalMinMax,
ExecEvalNullIf), neither do we do it for *function* invocations directly
in the executor (prominently node[Window]Agg.c), but we do it for
trigger invocations. That's, uh, a bit weird and hard to explain.
- Andres