SEPURI-SAI-KRISHNA opened a new pull request, #29123:
URL: https://github.com/apache/flink/pull/29123
## What is the purpose of the change
`OVERLAY` returns wrong results for several argument combinations. The first
row needs no unusual data:
| Expression | Returns | Expected |
|---|---|---|
| `OVERLAY('abcdef' PLACING 'X' FROM 2 FOR 0)` | `aX` | `aXbcdef` |
| `OVERLAY('a😀b' PLACING 'X' FROM 2 FOR 1)` | `aX` + unpaired surrogate +
`b` | `aXb` |
| `OVERLAY('abc' PLACING '😀' FROM 2)` | `a😀` | `a😀c` |
| `OVERLAY('123456789' PLACING 'abc' FROM 2 FOR 2147483647)` |
`StringIndexOutOfBoundsException` | `1abc` |
In `SqlFunctionUtils#overlay`: a `len > 0` guard drops the tail when the
replaced length is zero,
offsets count UTF-16 code units rather than characters, and `int len = (int)
length` wraps.
## Brief change log
- Count the start position and the replaced length in code points, using the
walk
`BinaryStringData#substring` already uses for `SUBSTRING`.
- A zero length replaces nothing, so the tail survives.
- `length` stays a `long`, so a large `FOR` neither wraps nor overflows the
end offset.
- Default the three-argument length to the replacement's code point count.
Left unchanged, because existing tests assert it: a start of zero or less,
or past the end,
returns the input; a negative `FOR` leaves no tail.
## Verifying this change
This change added tests and can be verified as follows:
- 9 cases added to `ScalarFunctionsTest#testOverlay`, all failing without
the fix.
- `ScalarFunctionsTest` and `SqlExpressionTest` pass, including the 18
existing `OVERLAY` expectations.
- Differentially checked against an independent implementation of the
SQL:2016 formula over 60,192
argument combinations covering the start and length boundaries: no
differences.
## 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**
- Anything that affects deployment or recovery: **no**
- The S3 file system connector: **no**
Replacing in a short string is faster (46 ns to 29 ns), one exactly-sized
`char[]` instead of a
growing `StringBuilder`. Replacing near the tail of a 2000-character string
is slower (940 ns to
2021 ns): converting a code point position to a char offset needs the same
walk `SUBSTRING` does.
## Documentation
- Does this pull request introduce a new feature? **no**
---
##### Was generative AI tooling used to co-author this PR?
- [X] Yes (please specify the tool below)
Generated-by: Claude Code (Opus 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]
