soumyakanti3578 commented on code in PR #6067:
URL: https://github.com/apache/hive/pull/6067#discussion_r2396361017
##########
ql/src/java/org/apache/hadoop/hive/ql/optimizer/calcite/translator/RexNodeConverter.java:
##########
@@ -699,15 +699,23 @@ protected RexNode convert(ExprNodeConstantDesc literal)
throws CalciteSemanticEx
calciteLiteral = rexBuilder.makeExactLiteral((BigDecimal) value,
calciteDataType);
break;
case FLOAT:
- calciteLiteral = rexBuilder.makeApproxLiteral(
+ // We mostly convert FLOAT to exact literal everywhere else, except when
+ // there is a suffix 'F'. See
TypeCheckProcFactory.NumExprProcessor#process
+ // Converting to an exact literal helps with deserialization by avoiding
+ // scientific notation.
+ calciteLiteral = rexBuilder.makeExactLiteral(
Review Comment:
I couldn't think of another way to resolve this. The crux of the issue is
that right now we almost always represents a double/float as a decimal, except
when we use their respective suffix, or when we do constant folding. I believe
the constant folding behavior is not intentional.
So the CBO plans can sometimes (rare) have the scientific notation and the
deserialized plan will never have one (we have a choice between never and
always, I chose to never use it as we rarely use scientific notation).
We need this change, either here or in another PR, so that our tests pass,
as we are relying on `Assertions.assertEquals` to compare the CBO and
deserialized plans.
I believe we should create a separate PR and "fix" this, so that there is
uniformity in the plans. There are not many plans which are affected - they all
are present in this PR.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
