-
Notifications
You must be signed in to change notification settings - Fork 543
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
Restrain JSON_TABLE table function parsing to MySqlDialect and AnsiDialect #1123
Changes from 5 commits
d7727a1
5f73e1a
be776e5
bed4af3
d7fdae5
6febd52
df1398b
0b225bf
e1e5c41
b7a4d3b
80a3dda
7f7d764
b27da0f
545c661
96ecfb1
8ce05b3
cd10ba5
7b803a3
ff4c995
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -7503,10 +7503,10 @@ | |
Ok(TableFactor::UNNEST { | ||
alias, | ||
array_exprs, | ||
with_offset, | ||
with_offset_alias, | ||
}) | ||
} else if self.parse_keyword(Keyword::JSON_TABLE) { | ||
} else if dialect_of!(self is MySqlDialect | AnsiDialect) && self.parse_keyword(Keyword::JSON_TABLE) { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I still don't think the dialect identity should be hardcoded. This should probably be a dialect.supports_json_table. And it should be true in the generic dialect. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I agree it would be nicer to do if There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't see why it should be true in generic dialect. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Agreed. As I mentioned early, this can be discussed separately. Although I wonder if it will result in many similar functions. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Yes I think it would. The codebase has a mix of styles currently -- both |
||
self.expect_token(&Token::LParen)?; | ||
let json_expr = self.parse_expr()?; | ||
self.expect_token(&Token::Comma)?; | ||
|
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.
Although
AnsiDialect
is for SQL:2011 standard based on its comment, seems it makes sense to add it in supported dialect.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.
It could be the default behavior for dialects which are likely to follow the standard to support the table function.
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 there are only very few dialects supporting this, I think it makes more sense to not add it into
GenericDialect
currently.