raminqaf opened a new pull request, #29785:
URL: https://github.com/apache/flink/pull/29785

   ## What is the purpose of the change
   
   `v[i]` on an array VARIANT accepts a BIGINT index, but the generated code 
cast it to `int` before the lookup. An index outside the INT range wrapped 
modulo 2^32 onto an existing element. With `v = [1]` and a BIGINT column `i`:
   
   ```sql
   SELECT v[i] FROM t;
   ```
   
   | `i`           | Before | After  |
   |---------------|--------|--------|
   | `4294967297`  | `1`    | `NULL` |
   | `-4294967295` | `1`    | `NULL` |
   
   The docs say an out-of-range index returns NULL, so the index is now 
range-checked as a `long` and narrowed to `int` only when it fits. Rejecting 
BIGINT during planning, as ARRAY does, would also fix it, but it would break 
queries that index with an in-range BIGINT today.
   
   ## Brief change log
   
     - `ScalarOperatorGens.generateIntegerKeyAccess` computes the zero-based 
index as a `long` and returns NULL when it falls outside `[0, 
Integer.MAX_VALUE]`.
   
   ## Verifying this change
   
   This change added tests and can be verified as follows:
   
     - Added `VARIANT_ARRAY_ACCESS_WITH_INDEX_OUTSIDE_INT_RANGE` to 
`VariantSemanticTest`. Without the fix, both rows return `1`.
   
   The new program runs SQL only. When a program has both `runSql` and 
`runTableApi` writing to one sink, the values sink keeps only the last job's 
rows, so the SQL step is never checked. That is also why 
`VARIANT_ARRAY_ACCESS_WITH_DIFFERENT_INDEX_TYPES` passes with `v[cast(4 as 
bigint)]` where it expects the third element.
   
   ## Does this pull request potentially affect one of the following parts:
   
     - Dependencies (does it add or upgrade a dependency): no
     - The public API, i.e., is any changed class annotated with 
`@Public(Evolving)`: no
     - The serializers: no
     - The runtime per-record code paths (performance sensitive): yes, one 
subtraction and two comparisons per VARIANT array index access
     - Anything that affects deployment or recovery: JobManager (and its 
components), Checkpointing, Kubernetes/Yarn, ZooKeeper: no
     - The S3 file system connector: no
   
   ## Documentation
   
     - Does this pull request introduce a new feature? no
     - If yes, how is the feature documented? not applicable
   
   ---
   
   ##### Was generative AI tooling used to co-author this PR?
   
   - [X] Yes (please specify the tool below)
   
   Generated-by: Claude Code 2.1.318 (Claude Opus 5.5)
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to