Repository navigation
fix(isthmus)!: honor floating-point arithmetic options - #1394
Conversation
SQL CONCAT and || now emit null_handling ACCEPT_NULLS for the standard Substrait concat function. Import accepts that behavior, including as a fallback preference, instead of silently discarding options. BREAKING CHANGE: Standard concat calls with null_handling preferences that do not include ACCEPT_NULLS, unknown options, or empty preference lists are rejected. Include ACCEPT_NULLS only when null propagation is acceptable.
Use one option policy for the standard concat, like, replace, starts_with, ends_with, strpos, substring, lower, upper and initcap mappings. Export the behavior implemented by the Calcite operator and reject import preferences that do not permit it. Other extensions and unmapped option policies are unchanged. BREAKING CHANGE: The covered standard string functions reject unknown options, empty preferences and preferences that do not include the mapped Calcite behavior. Allow that behavior only when it is acceptable for the query.
Export and validate TIE_TO_EVEN rounding for native FP32/FP64 add, subtract, multiply and divide from spec v0.103.0. Divide uses NAN for domain errors. Reject explicit division-by-zero preferences while the pinned spec's IEEE description conflicts with IEEE 754 behavior. BREAKING CHANGE: Isthmus rejects unsupported or ambiguous floating-point arithmetic option preferences instead of silently ignoring them.
|
Warning Review limit reachedYou've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Next included review available in 5 minutes. View limit detailsLimit details: You’ve used all 2 included reviews currently available. Review configuration: ⚙️ Run configuration
📒 Files selected for processing (7)
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configuration
📒 Files selected for processing (8)
Included review availability: This review used your included allowance. Your plan provides up to 2 included reviews per hour; 0 remain after this review. 📝 SummarySummary by CodeRabbit
WalkthroughFloating-point arithmetic options are generated for supported Calcite arithmetic calls and resolved during Substrait-to-Rex conversion. Tests cover option validation, execution, export, and SQL round-trips. ChangesFloating-point arithmetic options
Priority: ➖ Normal Estimated code review effort: 3 (Moderate) | ~20 minutes Change: Bug fix Sequence Diagram(s)sequenceDiagram
participant ExpressionRexConverter
participant ScalarFunctionConverter
participant FloatingPointFunctionOptions
ExpressionRexConverter->>ScalarFunctionConverter: Pass complete scalar-function invocation
ScalarFunctionConverter->>FloatingPointFunctionOptions: Resolve invocation options for selected operator
FloatingPointFunctionOptions-->>ScalarFunctionConverter: Return selected operator or reject unsupported options
ScalarFunctionConverter-->>ExpressionRexConverter: Return resolved operator
Suggested reviewers: Merge Risk: ⚪ Minimal · up to No actionable merge-blocking issue was established for the supported floating-point arithmetic calls. 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)✅ Passed checks (4 passed)✨ Finishing Touches 💡 1🛠️ Fix failing CI checks 💡
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
Could you please rerun the editorconfig job? |
nielspardon
left a comment
There was a problem hiding this comment.
This PR, #1390, #1392, #1393 and #1395 each set .options(XxxOptions.forCall(...)) on the same line in ScalarFunctionConverter.generateBinding, and the last three also add the same getSqlOperatorFromSubstraitFunc(ScalarFunctionInvocation) overload, so every merge after the first has to recombine them by hand. Could you land one shared seam first — a single overload plus a list of option policies that both directions iterate — and rebase the family onto it?
nielspardon
left a comment
There was a problem hiding this comment.
Thanks — the promotion fix and the move onto the shared policies look good. Please also extend the BREAKING CHANGE: footer to say that exported FP add/subtract/multiply/divide now carry rounding (and on_domain_error for divide), since that changes the plans Isthmus produces, not just the ones it accepts.
|
next one to merge with main with conflicts |
For FP32/FP64 add, subtract, multiply and divide, export rounding=TIE_TO_EVEN. Divide also exports on_domain_error=NAN. Import requires these modes, directly or as a fallback.
Division-by-zero options remain unsupported because the extension's IEEE description and LIMIT behavior differ from Java division. Leave that option unset on export. Matching is case-insensitive; undeclared values are rejected before fallback selection.
Part of #1173.
BREAKING CHANGE: Unsupported floating-point preferences are rejected. Exported arithmetic calls gain rounding=TIE_TO_EVEN; divide also gains on_domain_error=NAN. Consumers without those policies must reject these plans. Undeclared values fail even with a supported fallback.