aharpervc commented on code in PR #1808:
URL:
https://github.com/apache/datafusion-sqlparser-rs/pull/1808#discussion_r2052848713
##########
src/parser/mod.rs:
##########
@@ -5135,6 +5146,63 @@ impl<'a> Parser<'a> {
}))
}
+ /// Parse `CREATE FUNCTION` for [SQL Server]
+ ///
+ /// [SQL Server]:
https://learn.microsoft.com/en-us/sql/t-sql/statements/create-function-transact-sql
+ fn parse_mssql_create_function(
+ &mut self,
+ or_alter: bool,
+ or_replace: bool,
+ temporary: bool,
+ ) -> Result<Statement, ParserError> {
+ let name = self.parse_object_name(false)?;
+
+ let parse_function_param =
+ |parser: &mut Parser| -> Result<OperateFunctionArg, ParserError> {
+ let name = parser.parse_identifier()?;
+ let data_type = parser.parse_data_type()?;
+ Ok(OperateFunctionArg {
+ mode: None,
+ name: Some(name),
+ data_type,
+ default_expr: None,
+ })
+ };
+ self.expect_token(&Token::LParen)?;
+ let args = self.parse_comma_separated0(parse_function_param,
Token::RParen)?;
+ self.expect_token(&Token::RParen)?;
+
+ let return_type = if self.parse_keyword(Keyword::RETURNS) {
+ Some(self.parse_data_type()?)
+ } else {
+ None
+ };
+
+ self.expect_keyword_is(Keyword::AS)?;
+ self.expect_keyword_is(Keyword::BEGIN)?;
+ let function_body =
Some(CreateFunctionBody::MultiStatement(self.parse_statements()?));
Review Comment:
This is to address a separate issue. The situation is addressed by the
"create_function_with_conditional" test case example, which runs verified_stmt
on this sql:
```mssql
CREATE FUNCTION some_scalar_udf()
RETURNS INT
AS
BEGIN
IF 1 = 2
BEGIN
RETURN 1;
END;
RETURN 0;
END
```
The difficulty is regarding the IF statement. The pre-existing
`parse_if_stmt` logic advances the parse past semi-colons (if any) before
looking for an `else` block. If there's no `else` block as in this example, the
next token will be part of the next statement after END's semi-colon.
That conflicts with the pre-existing logic in `parse_statement_list`, which
unconditionally required a semi-colon after each parsed statement.
Therefore, this example would incorrectly be a parser error. To work around
that limitation I added this conditional logic to parse_statement_list to
inspect the previous statement for an IF statement end block. If found, no semi
colon is expected.
---
Thinking about it some more, I suppose it would be better to keep that
concern inside the parse_if_stmt function rather than bleeding out into
parse_statement_list. I've done that now on the branch, thoughts?
--
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: github-unsubscr...@datafusion.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: github-unsubscr...@datafusion.apache.org
For additional commands, e-mail: github-h...@datafusion.apache.org
