[
https://issues.apache.org/jira/browse/IMPALA-14903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18096008#comment-18096008
]
ASF subversion and git services commented on IMPALA-14903:
----------------------------------------------------------
Commit ba4dfc90bbaa75bf7ce0412b7171ae7aade30028 in impala's branch
refs/heads/master from Steve Carlin
[ https://gitbox.apache.org/repos/asf?p=impala.git;h=ba4dfc90b ]
IMPALA-14904: Calcite planner: Enable width_bucket function
This commit enables the width_bucket function. The code for
resolving/coercing decimal operand types had to be refactored and
modified.
The following fixes were needed to enable this:
- The config.fmpp now treats width_bucket as a non-reserved word so
that it can be parsed as a function name.
- After IMPALA-14903, the return type is no longer modified, so no check is
needed within CoerceNodes when resolving the function.
- If the operand for the aggregation function in CoerceNodes is a decimal,
it will simply derive the operand from the input if the function has a decimal
wildcard as an operand. If the decimal type is explicitly specified for the
aggregate function, a cast may be needed, so the type returned by the UDF
function is used.
- CoerceNodes now checks the precision and scale for casting in addition to
just the datatype
- CoerceOperandShuttle coerces the decimal operands
- If it is a binary arithmetic or binary comparison, there is no need for
coercing since the backend can handle different decimal types for these
functions
- If the return type is a decimal, then the common type has already been
determined through inferReturnType in the validation stage and this can
be used.
- If the return type is something other than a decimal, the common type
is derived, and an exception is thrown if there is no common type. This
is tested within the test_decimal_fuzz.py e2e test.
- A small fix was made to the FunctionResolver which now uses the actual
datatypes instead of a 'normalized' wildcard type for resolving.
- There are several instances where the TypeCompatibility.DEFAULT is used,
but this is incorrect for Decimal V2, which is the only mode supported
by the Calcite planner. The TypeCompatibility.STRICT_DECIMAL is used instead.
- The ImpalaTypeFactoryImpl was created to handle compatible types across rows
in a values clause. This acts well as a singleton object, so there are multiple
places that have been changed to handle this.
- The ImpalaTypeCoercionImpl.binaryComparison method has been added to prevent
casting on binary comparisons for decimals with different precisions and/or
scales.
Change-Id: I2944fde1301e48b3fb0c29be7290b1ad9533e5b6
Reviewed-on: http://gerrit.cloudera.org:8080/24271
Tested-by: Impala Public Jenkins <[email protected]>
Reviewed-by: Michael Smith <[email protected]>
> Calcite planner: Simplify String RelDataType
> --------------------------------------------
>
> Key: IMPALA-14903
> URL: https://issues.apache.org/jira/browse/IMPALA-14903
> Project: IMPALA
> Issue Type: Sub-task
> Reporter: Steve Carlin
> Assignee: Steve Carlin
> Priority: Major
>
> By default, Calcite always sets string literals to type "char" whereas Impala
> needs string literals to be type "string".
> The current code committed works around this by creating a cast around the
> column. This complicated the code. For example, A Values RelNode cannot have
> a cast, so a Project RelNode had to be created on top of a Values RelNode to
> handle the cast.
> This code should be simplified
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
