[
https://issues.apache.org/jira/browse/CALCITE-7450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18068315#comment-18068315
]
Stamatis Zampetakis commented on CALCITE-7450:
----------------------------------------------
Is this problem specific to custom functions? If not then it would be better to
modify the summary and put examples using built-in/standard functions. Same
goes for the tests in the PR.
The "Bug" prefix in the summary is redundant. Just by writing "ValuesReduceRule
incorrectly drops tuples from Values" is clear that we are talking about a bug
in a specific rule. Please rephrase accordingly.
> Bug in ValuesReduceRule dropping LogicalValues incorrectly
> ----------------------------------------------------------
>
> Key: CALCITE-7450
> URL: https://issues.apache.org/jira/browse/CALCITE-7450
> Project: Calcite
> Issue Type: Bug
> Components: core
> Affects Versions: 1.41.0, 1.42.0
> Reporter: Darpan Lunagariya (e6data computing)
> Priority: Minor
> Labels: pull-request-available
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> When we have *custom functions* defined and use them on LogicalValues, the
> ValuesReduceRule will drop the tuples in a wrong way, which it should not do.
> The project expression reduction handles it correctly and it specifically
> checks that after reduction, did the RexCall reduced into RexLiteral or not,
> if not, then we return at that time, but this is not handled in filter
> expression reduction.
> Below are the relevant snippets from that rule:
> *For project:*
> {code:java}
> if (projectExprs != null) {
> ++changeCount;
> final ImmutableList.Builder<RexLiteral> tupleBuilder =
> ImmutableList.builder();
> for (; i < fieldsPerRow; ++i) {
> final RexNode reducedValue =
> reducibleExps.get((row * fieldsPerRow) + i);
> if (reducedValue instanceof RexLiteral) {
> tupleBuilder.add((RexLiteral) reducedValue);
> } else if (RexUtil.isNullLiteral(reducedValue, true)) {
> tupleBuilder.add(rexBuilder.makeNullLiteral(reducedValue.getType()));
> } else {
> return;
> }
> }
> valuesList = tupleBuilder.build();
> } else {
> valuesList = values.getTuples().get(row);
> }
> {code}
> *For filter:*
> {code:java}
> if (conditionExpr != null) {
> final RexNode reducedValue =
> reducibleExps.get((row * fieldsPerRow) + i);
> ++i;
> if (!reducedValue.isAlwaysTrue()) {
> ++changeCount;
> continue;
> }
> }
> {code}
>
> For filter conditions, we just check
> {code:java}
> !reducedValue.isAlwaysTrue(){code}
> which will always be true in case of RexCall and that tuple will be dropped
> incorrectly, instead, we should just return from that rule, as done in
> reducing the project expression.
>
> Here is one example:
> {code:sql}
> SELECT * FROM (VALUES (0, 1, 2), (3, 4, 5)) AS t(a, b, c) WHERE
> CUSTOM_FUNC(t.a) > 2
> {code}
> I have just registered CUSTOM_FUNC in operator table, but I did not register
> Janino CallImplementor. Possibility is that this function is executed at
> runtime and some application just expect calcite to produce the Plan for it.
> For this query,
> {code:java}
> // RelNode tree after conversion to RelNode from SqlNode:
> LogicalProject(A=[$0], B=[$1], C=[$2])
> LogicalFilter(condition=[>(CUSTOM_FUNC($0), 2)])
> LogicalValues(tuples=[[{ 0, 1, 2 }, { 3, 4, 5 }]])
> // RelNode tree applying the rule:
> LogicalValues(tuples=[[]])
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
