On 2025-Feb-18, Sami Imseih wrote:
> > 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?
In the meantime, here's v28 which is Dmitry's v27 plus pgindent. No
other changes. Dmitry, were you planning to submit a new version?
--
Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/
"The problem with the future is that it keeps turning into the present"
(Hobbes)
