Re: pg_stat_statements and "IN" conditions

> > > It's not a question about whether it's possible to implement this,
> > > but about whether it makes sense. In case of plain constants it's
> > > straightforward -- they will not change anything meaningfully and
> > > hence could be squashed from the query. Now for a function, that
> > > might return different values for the same set of constant
> > > arguments, it's much less obvious and omitting such expressions
> > > might have unexpected consequences.
> >
> > query jumbling should not care about the behavior of the function. If
> > we take a regular call to a volatile function, we will generate the
> > same queryId for every call regardless of the input to the function.
> > Why does the in-list case need to care about the volatility of the
> > function?
>
> I feel quite insecure about this idea TBH. At least with immutable
> functions I don't expect the system to behave wildly different than with
> actual constants. What non-immutable functions do you have in mind that
> would be useful to fold as if they were constants in the IN list in such
> a query?

I don't have an example of non-immutable functions that should be folded,
but I also don't think query jumbling should care about the
function's volatility at all.

When dealing with FuncExpr, Why can't we simply skip merging when
func->funcformat != COERCE_IMPLICIT_CALL and the arguments
to the function are not constants? Meaning that anytime we have either
explicit casts or explicit function calls, this makes the list not eligible
for merging. See the attached .txt file to demonstrate what I am thinking.
This attached passes all the v28 test cases, but we will need to add tests
for implicit casts and external parameters.

--

Sami