xitep commented on code in PR #2185:
URL:
https://github.com/apache/datafusion-sqlparser-rs/pull/2185#discussion_r2747100412
##########
src/parser/mod.rs:
##########
@@ -14185,25 +14185,35 @@ impl<'a> Parser<'a> {
/// Parse a `CONNECT BY` clause (Oracle-style hierarchical query support).
pub fn parse_connect_by(&mut self) -> Result<ConnectBy, ParserError> {
- let (condition, relationships) = if
self.parse_keywords(&[Keyword::CONNECT, Keyword::BY]) {
- let relationships = self.with_state(ParserState::ConnectBy,
|parser| {
- parser.parse_comma_separated(Parser::parse_expr)
+ let (condition, relationships, nocycle) = if self
+ .parse_keywords(&[Keyword::CONNECT, Keyword::BY])
+ {
+ let (relationships, nocycle) =
self.with_state(ParserState::ConnectBy, |parser| {
Review Comment:
yes, that's good idea! and i'll go for it, since `sqlparser-rs` wants to be
generic and cover many dialects.
however, there's a subtle difference between the two branches:
at least for `Oracle`, an initial `START WITH ...` _must be followed_ by a
`CONNECT BY ...`; whereas an initial `CONNECT BY` _may have_ a `START WITH ...`
follower.
with the `Vec<ConnectByKind>`, one can validate this afterwards; similarly
the `loop` implies that a `CONNECT BY ... START WITH ... CONNECT BY ... CONNECT
BY` would be parsed successfully, which the client would have to validate (and
very likely reject.)
i guess it boils down to what `sqlparser-rs` wants be, either
"strictly-typed" or "duck-typed", figuratively speaking. personally i'm rather
inclined towards the former, since it takes away the burden from the
clients and centralises know-how into the (shared) library. (just like most
of the time, it's simply a trade-off.)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
