Tom Lane писал 2022-01-18 19:53:
Alexander Pyhalov <a.pyha...@postgrespro.ru> writes:
[ updated patch ]
Thanks for updating the patch. (BTW, please attach version numbers
to new patch versions, to avoid confusion.)
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.
Hi.
I think, I can extend it to allow any stable function (not just
immutable/sqlvalues) in is_foreign_expr(), but not so sure about
"expression".
Perhaps, at top of deparseExpr() we can check that expression doesn't
contain vars, params, but contains stable function, and deparse it as
param.
This means we'll translate something like
explain select * from t where d > now() - '1 day'::interval;
to
select * from t where d > $1;
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".
What do we save if we don't ship whole expression as param, but only
stable functions? Allowing them seems to be more straightforward.
--
Best regards,
Alexander Pyhalov,
Postgres Professional
