#121 Parse nested case statements

[teyc]

Parse CASE statements according to this grammar so that nested case statements are parsed correctly #121

        /// -- Simple CASE expression:
	/// CASE input_expression
	/// WHEN when_expression THEN result_expression [ ...n ]
	/// [ ELSE else_result_expression ]
	/// END
	///
	/// -- Searched CASE expression:
	/// CASE
	/// WHEN Boolean_expression THEN result_expression [ ...n ]
	/// [ ELSE else_result_expression ]
	/// END

Throws a TSQLParseException indicating point of error if the syntax is not correct.

The CaseExpression has been fleshed out with InputExpression and WhenExpressions properties to aid in code generation.

Several tests have been added:

• CaseExpression_Else_Is_Optional
• CaseExpression_ParseException
• CaseExpression_Inside_CaseExpression
• CaseExpression_Trailing_Comments_Stress_Test

The is a known bug where the parser will parse CASE WHEN END END successfully. This will require additional validation in ValueExpressionParser.

[bruce-dunwiddie]

Thank you. I'll find some time to review everything soon.

[teyc]

Sorry Bruce this PR introduces a regression because ValueExpression parser does not handle TBL.COL IS NULL.

After further research I’ve decided to switch over to Microsoft.TransactSql.ScriptDom parser instead as it appears to be the default engine used in MSSQL and was able to parse a complex thousand line stored proc correctly.

[bruce-dunwiddie]

The MS parsers obviously have the most features. There are a few different MS parsers, but at the time, there was no fast SQL parser. It was something like 1,000x faster than the MS parser. Since then, MS has released a much faster parser, that I was reasonably happy with the speed of, that is probably Microsoft.TransactSql.ScriptDom. Some people still don't like to take the licensing and dependency chain from the MS parsers. I've never truly liked any of their object models either. So there is room for both to coexist, for different use cases.