Skip to content

[AURON #2710] Align native chr with Spark character semantics - #2712

Open
lyne7-sc wants to merge 3 commits into
apache:masterfrom
lyne7-sc:fix/chr-spark-semantics
Open

lyne7-sc wants to merge 3 commits into
apache:masterfrom
lyne7-sc:fix/chr-spark-semantics

Conversation

@lyne7-sc

Copy link
Copy Markdown
Contributor

Which issue does this PR close?

Closes #2710

Rationale for this change

Native chr uses Unicode code point semantics, causing results to differ from Spark. For example, chr(321) returns Ł instead of A, and negative inputs raise an error instead of returning an empty string.

What changes are included in this PR?

  • Route Chr to a Spark-compatible Spark_Chr implementation.
  • Return an empty string for negative inputs, use the low 8 bits for non-negative inputs, and preserve NULLs.

Are there any user-facing changes?

Native chr now matches Spark for negative inputs and values.

How was this patch tested?

Added coverage:

  • test_string_chr checks scalar and array inputs, including negative values, NUL, wraparound, NULLs, and Int64 boundaries.
  • Chr uses Spark byte-range character semantics compares chr and its hexadecimal output against vanilla Spark using Parquet column inputs and requires native operators.

Was this patch authored or co-authored using generative AI tooling?

  • Yes
  • No

Generated-by: OpenAI Codex GPT-6.1-Sol

ASF guidance: https://www.apache.org/legal/generative-tooling.html

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Native chr does not preserve Spark character semantics

1 participant