[
https://issues.apache.org/jira/browse/CALCITE-3435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16962661#comment-16962661
]
Feng Zhu commented on CALCITE-3435:
-----------------------------------
The root cause seems to be related with incorrect return type inference.
For mod funtion, the return type is inferred as Integer.
(
https://github.com/apache/calcite/blob/977ea0d96f1f8e4225b6e27f02d86d0ea5aebb9a/core/src/main/java/org/apache/calcite/rel/type/RelDataTypeSystem.java#L356)
{code:java}
MOD(33.5:DECIMAL(3, 1), 7:Integer) -> Integer{code}
Consequently, in the codegen stage, the floor implementor is ignored directly.
I tried to fix it, but the javaDoc says:
"The default implementation is SQL:2003 compliant: the declared type of the
result is the declared type of the second operand (expression divisor)"
Hey [~julianhyde], is it a standard? I'd like to hear your voice.
> floor(mod(33.5,7)) wrongly returns 5.5
> --------------------------------------
>
> Key: CALCITE-3435
> URL: https://issues.apache.org/jira/browse/CALCITE-3435
> Project: Calcite
> Issue Type: Bug
> Affects Versions: 1.16.0, 1.21.0
> Reporter: jiezouSH
> Priority: Minor
>
> mod's return type is
> chain(DECIMAL_MOD_NULLABLE, ARG1_NULLABLE),
> but mod(33.5,7)'s result is 5.5, not in line with ARG1_NULLABLE.
> This causes floor(mod(33.5,7)) wrongly returns 5.5
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
