-
Notifications
You must be signed in to change notification settings - Fork 564
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
[ClickHouse] Add support for WITH FILL to OrderByExpr #1330
Conversation
ClickHouse supports the ORDER BY ... WITH FILL modifier: https://clickhouse.com/docs/en/sql-reference/statements/select/order-by#order-by-expr-with-fill-modifier WITH FILL itself supports a simple "from", "to", and "step" parameters, and a more sophisticated INTERPOLATE option.
972f46a
to
815ee5b
Compare
One question I had around the naming - do we like The values describe and "interpolation" which is why I named it that way to begin with, but I don't feel strongly either way. |
I added some tests for validation that invalid syntax is rejected in 4068bb3. This required me to add a validation function specifically for The only other way I could think to tackle this type of validation would be to change the struct OrderByClause {
order_bys: Vec<OrderByExpr>,
interpolate: Option<InterpolateArg>,
} but that seems much more disruptive to everyone who uses |
ebcd31e
to
4068bb3
Compare
src/parser/mod.rs
Outdated
@@ -7888,7 +7888,9 @@ impl<'a> Parser<'a> { | |||
let body = self.parse_boxed_query_body(0)?; | |||
|
|||
let order_by = if self.parse_keywords(&[Keyword::ORDER, Keyword::BY]) { | |||
self.parse_comma_separated(Parser::parse_order_by_expr)? | |||
let order_by_exprs = self.parse_comma_separated(Parser::parse_order_by_expr)?; | |||
self.validate_order_by_exprs_for_interpolate_and_with_fill(&order_by_exprs)?; |
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 so the parser generally doesn't do semantic validations explicitly except for maybe trivial cases, in this case it seems correct to have the invalid state non-representable in the AST, it does become a bit invasive of a change but that should be fine since it would leave us with a more accurate representation of the syntax
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 think we can likely skip this validation function in any case. To clarify, I think the current approach having interpolate in the OrderByExpr
would be incorrect/misleading (since the property isn't part of the order by expression and isn't applicable to other context where order by is used).
I think we can change the current representation in Query from:
Query {
pub order_by: Vec<OrderByExpr>,
}
to either
struct Query {
pub order_by: Vec<OrderByExpr>,
interpolate: Option<Interpolate>
}
or
struct OrderBy {
exprs: Vec<OrderByExpr>,
interpolate: Option<Interpolate>
}
Query {
pub order_by: OrderBy,
}
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've updated the structure of Query.order_by
(the second example) since INTERPOLATE
feels more associated with ORDER BY
instead of the base query itself.
Pull Request Test Coverage Report for Build 10019614247Details
💛 - Coveralls |
Thanks @nickpresta and @iffyio It looks like there are still a few suggestions outstanding on this PR. Just FYI I am hoping to get a sqlparser-rs release out tomorrow #1296 and will include this in the release if it is ready by then |
…nto add-order-by-expr-with-fill
3e8b141
to
85fae63
Compare
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.
LGTM
…nto add-order-by-expr-with-fill
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.
Left a couple comments, otherwise I think this looks good!
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.
One minor comment re pulling out the dialect check, LGTM! cc @alamb
src/parser/mod.rs
Outdated
// Parse a set of comma seperated INTERPOLATE expressions (ClickHouse dialect) | ||
// that follow the INTERPOLATE keyword in an ORDER BY clause with the WITH FILL modifier | ||
pub fn parse_interpolations(&mut self) -> Result<Option<Interpolate>, ParserError> { | ||
if dialect_of!(self is ClickHouseDialect | GenericDialect) |
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 can move this dialect check outside the function and to the caller, and have the function only care about the parsing logic.
one minor, we can also avoid nesting the function body by returning early
if !self.parse_keyword(Keyword::INTERPOLATE) {
return Ok(None)
}
if self.consume_token(...)
Ok(Some(...))
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.
Done in 000e08d. Thanks!
Hey @alamb - is this something that can be merged into Thank you! |
Sure thing -- sorry @nickpresta. I am sorry for the delay. I pushed a commit to try and resolve a test failure and hope to merge this in once the CI completes |
Co-authored-by: Andrew Lamb <andrew@nerdnetworks.org>
Co-authored-by: Andrew Lamb <andrew@nerdnetworks.org>
ClickHouse supports the
ORDER BY ... WITH FILL
modifier:https://clickhouse.com/docs/en/sql-reference/statements/select/order-by#order-by-expr-with-fill-modifier
WITH FILL
itself supports a simple "from", "to", and "step" parameters, and a more sophisticatedINTERPOLATE
option.