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.
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
Leverage more engine capabilities in data skipping 2/n #83
Leverage more engine capabilities in data skipping 2/n #83
Changes from 2 commits
33854a4
db8ef02
6b5c85e
aa44f36
5bc24e7
8870b88
c8f638b
3bd54ad
3a9e06c
0404430
37ac4d1
de03ca0
dfb981c
34d6a3d
6cb4fe4
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
We could use
|
at L200, to make sure we only match known operations? But I think the sub-match at L203 already gives that compile-time safety?Or, perhaps it's enough to do this?
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.
Actually, would something like this work?
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.
nice, it does! powerful pattern matching must be one of the features I appreciate most in programming languages :)
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.
Why a new top-level expression type? Can
Distinct
to be a newBinaryOperator
instead?(BinaryOperation { op, left, right }, _) => { ... let eval: Operation = match op { ... Equal => |l, r| eq(l, r).map(wrap_comparison_result), NotEqual => |l, r| neq(l, r).map(wrap_comparison_result), + Distinct => |l, r| distinct(l, r).map(wrap_comparison_result), };
(bonus: whatever type checking we eventually add would then benefit all comparison operators)
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.
Aside: In a future PR that adds better type checking, should we introduce a
ComparisonOperator
sub-enum, for things that map (T, T) -> bool? And if we did that, should we also add anAlgebraicOperator
(**) sub-enum, for things that map (T, T) -> T? That would capture the vast majority of binary operations in a structured way, while still allowing to add arbitrary other binary operators if needed (***)?Edit: In retrospect, this seems very related to your question #83 (comment)
(**) According to Wikipedia,
(***) Perhaps ironically, arrow's
nullif
function is one such operatorThere 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.
https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=a1ab3228a14926b86b9c993011926299
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.
aside: too bad rust doesn't support named args for passing magic constants...
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.
yeah, you can always put it in a comment
... DataType::BOOLEAN, /* nullable */ true)
, but it's not nearly as niceThere 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.
TIL about collect_vec! But why use it only here? Wouldn't it work just as well for L158, etc?
Similarly, it seems like we could use try_collect at e.g. L171 above and L190 below?
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.
to be honest, i am not consistent in that. its only available if
Itertools
is in scope, so if that is availabe i start using it, and may just have realized too late.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.
What is the difference between
None
andSome(None)
here?(trying to understand why we need nested options like that?)
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.
None
means no value is present in the map,Some(None)
means there is a value and its 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.
Makes sense. Worth a quick code comment, perhaps?