-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Combine Expr::Wildcard
and Wxpr::QualifiedWildcard
, add wildcard()
expr fn
#8105
Conversation
.aggregate(vec![col("b")], vec![count(Wildcard)])? | ||
.sort(vec![count(Wildcard).sort(true, false)])? | ||
.aggregate(vec![col("b")], vec![count(wildcard())])? | ||
.sort(vec![count(wildcard()).sort(true, false)])? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this shows the difference in API for users (calling wildcard()
), which I think is more consistent with other functions
projected_expr.extend(expand_wildcard(input_schema, &plan, None)?) | ||
} | ||
Expr::QualifiedWildcard { ref qualifier } => projected_expr | ||
.extend(expand_qualified_wildcard(qualifier, input_schema, None)?), | ||
Expr::Wildcard { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
here is the only place where Wildcard and QualifiedWildcard are treated substantially differently
@@ -1052,11 +1054,6 @@ impl TryFrom<&Expr> for protobuf::LogicalExprNode { | |||
})), | |||
} | |||
} | |||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As a bonus, qualified wildcards can now be serialized to/from proto -- I doubt this feature is widely used, but it is nice to avoid the rough edge I think
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense to me. Thanks for taking this 👍
pub fn wildcard() -> Expr { | ||
Expr::Wildcard { qualifier: None } | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need a fn wildcard_with_qualifier()
or fn wildcard(qualifier: None)
? Though it's not used in our examples.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was thinking that it was such a niche usecase that if anyone needed the qualifier
they could make it explicitly via Expr::Wildcard{ qualifier: Some(...)}
, but that is indeed messier
I would be happy to add qualified_wildcard
or similar if others think it would be valuable
I plan to leave this PR open for a few days to given anyone who might be interested time to comment. Thank you @waynexia for the review 🙏 |
Which issue does this PR close?
Closes #8104
Rationale for this change
Per #8104
As @waynexia points out on #8008 (comment), having
Expr::Wildcard
andExpr::QualifiedWildcard
is confusing as they are both representing the same basic pattern,*
Specifically, I think it could make subtle bugs more likely (e.g. using
Expr::Wildcard
instead of usingExpr::QualifiedWildcard
)What changes are included in this PR?
Expr::Wildcard
toExprWildcard { qualifier: Option<String> }
and removeExpr::QualifiedWildcard
Are these changes tested?
Are there any user-facing changes?
Yes, users can't use
Expr::Wildcard
anymore -- they either have to useExpr::Wildcard { qualifier: None}
orwildcard()