SEPURI-SAI-KRISHNA opened a new pull request, #29004:
URL: https://github.com/apache/flink/pull/29004
## What is the purpose of the change
`LPAD` and `RPAD` measure length in UTF-16 code units instead of characters.
When the requested length falls in the middle of a supplementary-plane
character, the function splits the surrogate pair and returns a string
containing an unpaired surrogate, which is not valid Unicode. The same
code-unit arithmetic also makes the result shorter than requested whenever the
base or the pad string contains such a character.
In the table below `E` stands for the single-character string U+1F600
GRINNING FACE, which UTF-16 encodes as the surrogate pair U+D83D U+DE00. It is
written as `E` so that this description stays within the Basic Multilingual
Plane.
| Expression | Returned, as UTF-16 code units | Note |
| --- | --- | --- |
| `LPAD(E, 1, 'x')` | `U+D83D` | unpaired high surrogate: the first half of
`E` |
| `RPAD(E, 1, 'x')` | `U+D83D` | unpaired high surrogate: the first half of
`E` |
| `RPAD('a', 4, E)` | `U+0061 U+D83D U+DE00 U+D83D` | pad split mid-pair,
trailing unpaired high surrogate |
| `LPAD(E, 3, 'x')` | `U+0078 U+D83D U+DE00` | valid Unicode, but 2
characters instead of 3 |
The documentation states that the length is measured in characters:
> Returns a new string from string1 left-padded with string2 to a length of
integer **characters**.
`E` is one character, so `LPAD(E, 1, 'x')` should return `E` unchanged
rather than half of it. This also matches `SPLIT`, which moved to code-point
iteration in FLINK-36267.
The failure is silent: no exception is thrown and nothing is logged. The
result is invalid UTF-16 and does not round-trip, so downstream string
functions and comparisons then operate on a value the query never produced.
## Brief change log
- `SqlFunctionUtils#lpad` and `#rpad` measure both the base and the pad
string in code points and slice only on character boundaries, building the
result with a `StringBuilder` instead of a fixed `char[len]`
- Padding is factored into a shared `appendPadding` helper that repeats
the pad string cyclically and stops mid-string only on a character boundary
- Scanning of the base stops after `len` characters via
`endOfFirstCodePoints`, so truncating a base far longer than the requested
length keeps the complexity of the previous implementation
- Added supplementary-plane cases to `ScalarFunctionsTest` and a new
`lpadRpadTestCases` set to `StringFunctionsITCase`
## Verifying this change
This change added tests and can be verified as follows:
- Added supplementary-plane cases to `ScalarFunctionsTest#testLPad` and
`#testRPad` covering truncation of a supplementary-plane base and padding with
a supplementary-plane pad string
- Added `lpadRpadTestCases` to `StringFunctionsITCase`, which exercises
the generated runtime code with field references rather than literals, so the
cases are not constant-folded at plan time. Basic Multilingual Plane cases are
included alongside the supplementary-plane ones to pin that existing behaviour
is unchanged
- Reverting only the `SqlFunctionUtils` change fails 24 of the new
`StringFunctionsITCase` assertions with results such as `expected: +I[<emoji>]
but was: +I[?]`, and passes all of them with the change applied
- `flink-table-runtime` full suite: 1813 tests, 0 failures.
`StringFunctionsITCase`: 571 tests, 0 failures. `ScalarFunctionsTest`: 99
tests, 0 failures
- A randomized differential check over 800k input combinations confirms
every result has exactly the requested number of code points and contains no
unpaired surrogate
## 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**. `SqlFunctionUtils` is an internal runtime class,
though the observable result of the `LPAD` and `RPAD` SQL functions changes for
supplementary-plane input, which is the point of the fix
- The serializers: **no**
- The runtime per-record code paths (performance sensitive): **yes**. Both
functions are per-record string functions. The implementation stops scanning
the base after `len` characters, so the truncation path stays proportional to
the requested length rather than the length of the input, matching the previous
implementation. The pad string is measured only when padding is actually needed
- 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**. It makes the
implementation match the documented behaviour, so no documentation change is
needed
---
##### 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]
