On November 26, 2016 8:06:26 AM PST, Tom Lane <t...@sss.pgh.pa.us> wrote: >Robert Haas <robertmh...@gmail.com> writes: >> On Fri, Nov 25, 2016 at 11:12 PM, Andres Freund <and...@anarazel.de> >wrote: >>> while working on my faster expression evaluation stuff I noticed >that a >>> lot of expression types that call functions don't call the necessary >>> functions to make track_functions work. >>> >>> ExecEvalFunc/ExecEvalOper (via ExecMakeFunctionResultNoSets) call >>> pgstat_init_function_usage/pgstat_end_function_usage, but others >like >>> ExecEvalRowCompare, ExecEvalMinMax, ExecEvalNullIf, >ExecEvalDistinct, >>> ExecEvalScalarArrayOp (and indirectly ExecEvalArrayCoerceExpr) >don't. >>> >>> Similarly InvokeFunctionExecuteHook isn't used very thoroughly. >>> >>> Are these worth fixing? I suspect yes. If so, do we want to >backpatch? > >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. Andres -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
