feat: Support arbitrary expressions in SQL JOIN constraints
#25132
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Closes #18654.
Updates
A long overdue rework of SQL "JOIN" constraint processing - much improved, in terms of clarity, robustness, and capability (for example, we now use
sqlparser-rs' ownVisitorfunctionality to associate left/right sides of the join condition; seeFindTableIdentifierfor details - this approach may be useful elsewhere, later).Improved implementation of
resolve_compound_identifier, adding additional handling for identifiers referring to columns created by multiple/consecutive joins that are not in the original/leftmost frame schema, and tidying up some other identifier resolution (mostly by preferringmatchoverif/elsechains).These improvements finally allow us to support expressions (and literals) in join constraints, not just column names. All existing tests pass, and plenty of new test coverage was added.
Example
Can now support a join condition on
"LOWER(<col>)":Previously this would have raised the following exception...
...but now we can better introspect into the SQL expression, we can support more.