|From:||Alexander Pyhalov <a(dot)pyhalov(at)postgrespro(dot)ru>|
|To:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|Cc:||Ranier Vilela <ranier(dot)vf(at)gmail(dot)com>, Zhihong Yu <zyu(at)yugabyte(dot)com>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: Push down time-related SQLValue functions to foreign server|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
Tom Lane писал 2022-01-18 19:53:
> Alexander Pyhalov <a(dot)pyhalov(at)postgrespro(dot)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.
I think, I can extend it to allow any stable function (not just
immutable/sqlvalues) in is_foreign_expr(), but not so sure about
Perhaps, at top of deparseExpr() we can check that expression doesn't
contain vars, params, but contains stable function, and deparse it as
This means we'll translate something like
explain select * from t where d > now() - '1 day'::interval;
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.
|Next Message||Tom Lane||2022-01-18 19:11:30||Re: Push down time-related SQLValue functions to foreign server|
|Previous Message||Andrew Dunstan||2022-01-18 18:58:34||Re: Adding CI to our tree|