MSSQL: Support THROW statement

[guan404ming]

Why

The MSSQL THROW statement was missing from the sqlparser, preventing parsing of T-SQL error handling code.

How

• Add THROW keyword and Statement::Throw AST variant with optional error_number, message, state
• Add parse_throw() handling both THROW (re-throw) and THROW num, msg, state forms
• Add tests for literal args, variable args, and argument-less re-throw

[guan404ming]

Hi @iffyio I would like modify the PR title to MSSQL: support THROW statement to better align the convention here but I found there is no edit button here for this pr. Could you help modify it, thanks!

[iffyio]

Done!

[guan404ming]

Thanks! Please let me know if there is anything could be better in this pr, thanks!

[iffyio]

we're slowly moving away from this representation over to having all statements wrapped in a named struct. As a result, can we do something like this instead?

struct Throw { ... }
Statement::Throw(Throw)

See the RAISE statement for an example

[guan404ming]

Thanks for your information. I just update with wrapped named struct.

[iffyio]

Suggested change

	Keyword::THROW => Ok(self.parse_throw()?),
	Keyword::THROW => {
	self.prev_token();
	self.parse_throw().map(Into::into)
	},

see RAISE for an example. we're moving to have the statement parsing functions return the actual struct instead of a Statement enum variant. Also it would be ideal that the parse_throw is a standalone function (able to parse a THROW statement) so we rewind the token before invoking it

[iffyio]

Suggested change

	if self.peek_token_ref().token == Token::SemiColon
	|| self.peek_token_ref().token == Token::EOF
	{
	return Ok(Statement::Throw {
	error_number: None,
	message: None,
	state: None,
	});
	}

I think we can skip this logic, it would be expected for the function to return an error if the input is empty (per the previous comment about making this function stand-alone)

[guan404ming]

Ok, that makes sense to me. Just moved~

[iffyio]

LGTM! Thanks @guan404ming!