Alexander Pyhalov <a.pyha...@postgrespro.ru> writes: > Tom Lane писал 2022-01-18 19:53: >> However, before we proceed any further with this patch, I think we >> really ought to stop and think about the question I raised last >> night: why are we building a one-off feature for SQLValueFunction? >> Wouldn't the same parameter-substitution mechanism work for *any* >> stable expression that doesn't contain remote Vars? That would >> subsume the now() case as well as plenty of others.
> This means we'll translate something like > explain select * from t where d > now() - '1 day'::interval; > to > select * from t where d > $1; Right. > The question is how will we reliably determine its typmod (given that I > read in exprTypmod() comment > "returns the type-specific modifier of the expression's result type, if > it can be determined. In many cases, it can't". I don't think we need to. If exprTypmod() says the typmod is -1, then that's what it is. > What do we save if we don't ship whole expression as param, but only > stable functions? Allowing them seems to be more straightforward. How so? Right off the bat, you get rid of the need for your own version of contain_mutable_function. ISTM this approach can probably be implemented in a patch that's noticeably smaller than what you have now. It'll likely be touching entirely different places in postgres_fdw, of course. regards, tom lane