Ramin Gharib created FLINK-41330:
------------------------------------
Summary: 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
{{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)
