[
https://issues.apache.org/jira/browse/FLINK-41330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ramin Gharib reassigned FLINK-41330:
------------------------------------
Assignee: Ramin Gharib
> VARIANT array access with a BIGINT index wraps around and returns the wrong
> element
> -----------------------------------------------------------------------------------
>
> Key: FLINK-41330
> URL: https://issues.apache.org/jira/browse/FLINK-41330
> Project: Flink
> Issue Type: Bug
> Components: Table SQL / Planner
> Affects Versions: 2.3.0
> Reporter: Ramin Gharib
> Assignee: Ramin Gharib
> Priority: Major
>
> {{v[i]}} on an array VARIANT narrows a BIGINT index to {{int}} before the
> lookup. An index outside the INT range wraps modulo 2^32^ and returns an
> element. The docs say an out-of-range index returns NULL.
> {code:sql}
> SELECT v[4294967297] AS a,
> v[CAST(4294967298 AS BIGINT)] AS b,
> v[4] AS c
> FROM (VALUES (PARSE_JSON('[10,20,30]'))) AS t(v);
> {code}
> ||Column||Expected||Actual||
> |a|NULL|10|
> |b|NULL|20|
> |c|NULL|NULL|
> The validator accepts any integer type as a VARIANT index, since
> {{SqlItemOperator}} checks {{SqlTypeFamily.INTEGER}}. The generated code then
> casts it in {{ScalarOperatorGens.generateIntegerKeyAccess}}:
> {code:java}
> $variantTerm.getElement((int) $keyTerm - 1);
> {code}
> {{(int) 4294967297L}} is 1, so {{a}} reads the first element. A plain ARRAY
> does not have this problem: {{ARRAY[10,20,30][CAST(2 AS BIGINT)]}} fails
> during planning with {{Integer expression type expected.}}
> *Proposal*
> Check a BIGINT index against the INT range before narrowing it, and return
> NULL when it falls outside, as the docs describe for any out-of-range index.
> Rejecting BIGINT during planning, as ARRAY does, would also fix it, but it
> would break queries that index with an in-range BIGINT today.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
