-
Notifications
You must be signed in to change notification settings - Fork 550
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
Add support for BigQuery ANY TYPE
data type
#1602
Conversation
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.
Thanks @MartinSahlen! The changes look reasonable to me, left a couple minor comments
src/parser/mod.rs
Outdated
@@ -8382,6 +8382,10 @@ impl<'a> Parser<'a> { | |||
Ok(DataType::Tuple(field_defs)) | |||
} | |||
Keyword::TRIGGER => Ok(DataType::Trigger), | |||
Keyword::ANY => { |
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.
Keyword::ANY => { | |
Keyword::ANY if self.peek_keyword(Keyword::TYPE) => { |
Thinking we can add this guard to ensure that it doesn't conflict with a custom data type that happens to be called ANY
?
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.
Ah yes that is much more in line with the desired / intended behavior. As the current approach would result in a parsing error should we come across an ANY type 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.
I tried implementing this change but it seems to break. hmm
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 this is the first time I'm touching the codebase, I needed to understand the general mechanisms. Your change worked in conjunction with let _ = self.parse_keyword(Keyword::TYPE);
, which makes intitutive sense after looking at the code in general.
tests/sqlparser_bigquery.rs
Outdated
// Templated | ||
concat!( | ||
"CREATE OR REPLACE TEMPORARY FUNCTION ", | ||
"my_function(param1 ANY TYPE) ", | ||
"AS (", | ||
"(SELECT 1)", | ||
")", | ||
), |
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.
Since the functionality itself is the data type, I'm thinking we can use a dedicated test for it? e.g fn test_parse_any_type()
? Also can we add a test case to demonstrate the behavior in the other comment what happens in a sql like CREATE TABLE foo (x ANY);
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.
Good point, I was in fact doing that but reverted to inlining the test with other UDFs. Not being sure what was the preferred pattern but makes sense!
ANY TYPE
data type
Thanks for the review and suggestions! I have now added the suggested changes and improvements, along with two seperate tests
|
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! Thanks @MartinSahlen!
cc @alamb
Thanks! |
As referenced in #1601 , here is a PR, with a test, that verifies correct parsing of BigQuery User-defined functions using templated SQL parameters (what a mouthful :D).
More docs on the actual feature/functionality in BQ can be found here: https://cloud.google.com/bigquery/docs/user-defined-functions
Thanks in advance for the consideration!
EDIT: This closes #1601