[
https://issues.apache.org/jira/browse/CALCITE-5862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17744661#comment-17744661
]
Tanner Clary edited comment on CALCITE-5862 at 7/19/23 2:54 PM:
----------------------------------------------------------------
I took a look at the PR, I am wondering how this affects dialects that do not
allow arrays of multiple types (BigQuery, for instance, throws an error that
looks like {{Array elements of types [INT64, STRING] do not have a common
supertype}} if you pass in the array {{[1, 'a']}}.
was (Author: JIRAUSER298151):
I took a look at the PR, I am wondering how this affects dialects that do not
allow arrays of multiple types (BigQuery, for instance, throws an error that
looks like {{Array elements of types {INT64, STRING} do not have a common
supertype}} if you pass in the array {{[1, 'a']}}.
> Incorrect spark semantics of array function when elements have Numeric and
> Character types
> ------------------------------------------------------------------------------------------
>
> Key: CALCITE-5862
> URL: https://issues.apache.org/jira/browse/CALCITE-5862
> Project: Calcite
> Issue Type: Bug
> Components: core
> Affects Versions: 1.34.0
> Reporter: Ran Tao
> Assignee: Ran Tao
> Priority: Major
> Labels: pull-request-available
>
> when run select array(1, 2, 'Hi')
> spark-sql (default)> select array(1, 2, 'Hi');
> ["1","2","Hi"]
> and calcite will cause {*}java.lang.NullPointerException: inferred array
> element type{*}.
> Spark supports both character and numeric types in the array, and the return
> type is character.
> In fact, calcite also allows both character and numeric types to exist in the
> operand type checker, but there is no corresponding processing logic in the
> return type inference, so an error is reported.
> We should fix this bug.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)