On 30.03.21 11:20, Peter Eisentraut wrote:
On 24.03.21 11:52, houzj.f...@fujitsu.com wrote:
+ if (!has_nonconst_input)
+ return ece_evaluate_expr(expr);
That's not okay without a further check to see if the comparison
function used
by the node is immutable.
On 24.03.21 11:52, houzj.f...@fujitsu.com wrote:
+ if (!has_nonconst_input)
+ return ece_evaluate_expr(expr);
That's not okay without a further check to see if the comparison function used
by the node is immutable. Compare Scal
> + if (!has_nonconst_input)
> + return ece_evaluate_expr(expr);
>
> That's not okay without a further check to see if the comparison function used
> by the node is immutable. Compare ScalarArrayOpExpr, for instance.
Thanks for poin
David Steele writes:
> Peter, thoughts on the new patch in [1]?
I'm not Peter, but I have a complaint about this bit:
+ if (!has_nonconst_input)
+ return ece_evaluate_expr(expr);
That's not okay without a further check to see i
On 1/19/21 8:16 PM, Hou, Zhijie wrote:
Attatching v3 patch, please consider it for further review.
Peter, thoughts on the new patch in [1]?
--
-David
da...@pgmasters.net
[1]
https://www.postgresql.org/message-id/ab53b3dbdbd6436f970f33b51ccd7dd3%40G08CNEXMBPEKD05.g08.fujitsu.local
Hi
Thanks for the review.
> It's a bit unfortunate now that between OpExpr, DistinctExpr, NullIfExpr,
> and to a lesser extent ScalarArrayOpExpr we will now have several different
> implementations of nearly the same thing, without any explanation why one
> approach was chosen here and another th
On 2021-01-12 07:43, Hou, Zhijie wrote:
I think this patch should be about a tenth the size. Try modeling it
on the T_SubscriptingRef-etc case, ie, use ece_generic_processing and
then ece_evaluate_expr to cover the generic cases. OpExpr is common
enough to deserve specially optimized code, but
> > I think this patch should be about a tenth the size. Try modeling it
> > on the T_SubscriptingRef-etc case, ie, use ece_generic_processing and
> > then ece_evaluate_expr to cover the generic cases. OpExpr is common
> > enough to deserve specially optimized code, but NullIf isn't, so shorter
>
> > I notice that there are no Nullif case in eval_const_expression.
> > Since Nullif is similar to Opexpr and is easy to implement, I try add
> > this case in eval_const_expressions_mutator.
>
> I think this patch should be about a tenth the size. Try modeling it on
> the T_SubscriptingRef-etc c
"Hou, Zhijie" writes:
> I notice that there are no Nullif case in eval_const_expression.
> Since Nullif is similar to Opexpr and is easy to implement,
> I try add this case in eval_const_expressions_mutator.
I think this patch should be about a tenth the size. Try modeling
it on the T_Subscripti
10 matches
Mail list logo
