Add support for `GO` batch delimiter in SQL Server #1809

aharpervc · 2025-04-11T16:51:40Z

Reference: https://learn.microsoft.com/en-us/sql/t-sql/language-elements/sql-server-utilities-statements-go

Lots of conventional SQL Server tooling supports GO, so it seems really useful & prudent to be able to parse it. I realize that strictly speaking, it isn't a SQL "statement". However, I think it makes sense to model here as a statement since it acts as one in all regards except documentation.

In terms of parsing, GO has some peculiarities I tried to express with the new tests, such as with regards to position and basically treating newline as a delimiter. This also starts to nudge on #1800, where newlines may possibly be interpreted as statement delimiters in a general case. However, my approach here for GO is isolated to only that statement, at least for the time being.

Also, this will conflict with #1808 when either is merged, because I'm adding things that end up being adjacent to each other which can confuse git, depending on merge strategy. There's no actual conflict.

iffyio · 2025-04-12T07:15:29Z

src/ast/mod.rs

+    Go {
+        count: Option<u64>,
+    },


Repr wise can we wrap the statement body in explicit structs? we're transitioning away from anonymous structs in order to make the API more ergonomic. Something like

struct GoStatement { count: Option<u64> } Statement::Go(GoStatement)

iffyio · 2025-04-12T07:16:50Z

src/parser/mod.rs

+                    // Treat batch delimiter as an end of statement
+                    if expecting_statement_delimiter && dialect_of!(self is MsSqlDialect) {
+                        if let Some(Statement::Go { count: _ }) = stmts.last() {
+                            expecting_statement_delimiter = false;
+                        }
+                    }


not sure I followed this part, what was the intention?

I tried to explain this in the commit message & the "multiple_gos" example in the test. Basically, we want this to parse as 4 statements:

SELECT 1; GO SELECT 2; GO

The second GO is terminated by EOF, so no problem. But the first GO cannot end with a semi colon (This overlaps with the ongoing "no semi-colons for statements" discussion but from a different angle). So we need to figure out how to parse it all out without the existing conventional semi-colon logic.

What I came up with is to basically just look for a GO and have that signal that we aren't then also looking for statement delimiter (eg, semi-colon). This also makes sense semantically because statements can't extend between batches, so any batch delimiter also functions as a statement delimiter.

In terms of the code, I worked out a perhaps slightly less confusing way to set whether or not a semi-colon is expected, here.

This branch can be updated accordingly if we agree over there

I've now done that due to another problem I noticed, for IF statements (new test case also added...)

iffyio · 2025-04-12T07:18:27Z

src/parser/mod.rs

@@ -617,6 +623,9 @@ impl<'a> Parser<'a> {
                }
                // `COMMENT` is snowflake specific https://docs.snowflake.com/en/sql-reference/sql/comment
                Keyword::COMMENT if self.dialect.supports_comment_on() => self.parse_comment(),
+                Keyword::GO if dialect_of!(self is MsSqlDialect) => {


Suggested change

Keyword::GO if dialect_of!(self is MsSqlDialect) => {

Keyword::GO => {

I think it should be fine to let the parser always accept the statement if it shows up. Technically if we wanted to gate it behind a feature then we could use a self.dialect.supports flag since the dialect_of macro is deprecated, but I think it makes more sense to let the parser accept unconditionally

iffyio · 2025-04-12T07:19:03Z

src/parser/mod.rs

@@ -15017,6 +15026,48 @@ impl<'a> Parser<'a> {
        }
    }

+    fn parse_go(&mut self) -> Result<Statement, ParserError> {


Suggested change

fn parse_go(&mut self) -> Result<Statement, ParserError> {

/// Parse [Statement::Go]

fn parse_go(&mut self) -> Result<Statement, ParserError> {

iffyio · 2025-04-12T07:22:16Z

src/parser/mod.rs

@@ -15017,6 +15026,48 @@ impl<'a> Parser<'a> {
        }
    }

+    fn parse_go(&mut self) -> Result<Statement, ParserError> {


One thing we could do, in the parse_stmt() function could we call self.prev_token() to rewind the Go keyword so that this function becomes self contained in being able to parse a full Go statement?

iffyio · 2025-04-12T07:26:03Z

src/parser/mod.rs

@@ -15017,6 +15026,48 @@ impl<'a> Parser<'a> {
        }
    }

+    fn parse_go(&mut self) -> Result<Statement, ParserError> {
+        // previous token should be a newline (skipping non-newline whitespace)


hmm I didn't look too closely but not sure I followed the function body on a high level, from the docs and the representation in the parser the Go statement only contains an optional int, so that I imagined all the function needs to do would be to maybe_parse(|parser| parser.parse_number_value()) or similar? The function is currently managing whitespace and semicolon but not super clear to me why that is required

Does my comment above & the code comment below, "using this peek function because we want to halt this statement parsing upon newline" help?

-- this should parse as `Go { Some(4) }` GO 4 -- this should parse as something like `Go { None }`, `Expr(4)` GO 4

Eg, the whitespace is meaningful for parsing

Ah interesting, I think it would be very helpful to add this example to the code to illustrate the implications,

Then for the function, I think using the peek_token_no_skip could simplify the impl. Something roughly like the following? to avoid manually tracking token counts and lookbacks

let count = loop { match self.peek_token_no_skip() { Token::Whitespace(Whitespace::Newline) | Token::Whitespace(Whitespace::SingleLineComment) | Token::EOF => { self.advance_token(); break None } Token::Whitespace(_) => { self.advance_token(); } _ => { break Some(self.parse_number()) } } };

Yes, I have something like that already for parsing the batch count, which doesn't need to look backwards and already uses peek_token_no_skip. I think between here & your other comment on the alias function, the concern is regarding the newline logic which looks backwards. I'll try and move that into a helper so it can be simplified.

iffyio · 2025-04-12T07:27:42Z

tests/sqlparser_mssql.rs

+    assert!(err.is_err());
+    assert_eq!(
+        err.unwrap_err().to_string(),
+        "sql parser error: Expected: newline before GO, found: ;"
+    );
+
+    let invalid_go_count = "SELECT 1\nGO x";
+    let err = ms().parse_sql_statements(invalid_go_count);
+    assert!(err.is_err());


Suggested change

assert!(err.is_err());

assert_eq!(

err.unwrap_err().to_string(),

"sql parser error: Expected: newline before GO, found: ;"

);

let invalid_go_count = "SELECT 1\nGO x";

let err = ms().parse_sql_statements(invalid_go_count);

assert!(err.is_err());

assert_eq!(

err.unwrap_err().to_string(),

"sql parser error: Expected: newline before GO, found: ;"

);

let invalid_go_count = "SELECT 1\nGO x";

let err = ms().parse_sql_statements(invalid_go_count);

since we're already unwrapping the error

Ah yes great point, done 👍

aharpervc · 2025-04-15T15:52:30Z

Rebased on main & updated

src/parser/mod.rs

iffyio · 2025-04-18T07:15:03Z

src/parser/mod.rs

@@ -15017,6 +15026,48 @@ impl<'a> Parser<'a> {
        }
    }

+    fn parse_go(&mut self) -> Result<Statement, ParserError> {
+        // previous token should be a newline (skipping non-newline whitespace)


Ah interesting, I think it would be very helpful to add this example to the code to illustrate the implications,

Then for the function, I think using the peek_token_no_skip could simplify the impl. Something roughly like the following? to avoid manually tracking token counts and lookbacks

let count = loop { match self.peek_token_no_skip() { Token::Whitespace(Whitespace::Newline) | Token::Whitespace(Whitespace::SingleLineComment) | Token::EOF => { self.advance_token(); break None } Token::Whitespace(_) => { self.advance_token(); } _ => { break Some(self.parse_number()) } } };

iffyio · 2025-04-18T07:20:04Z

tests/sqlparser_mssql.rs

+
+#[test]
+fn parse_mssql_go_keyword() {
+    let single_go_keyword = "USE some_database;\nGO";


Can we have one of the test cases use ms().one_statement_parses_to(sql, canonical)? looking at the tests its unclear what the behavior of the parser is in terms of serializing an AST that has GO statements in it, and that it needs special behavior to inject new lines manually I imagine

I'm unsure the best way to approach this question. one_statement_parses_to requires one statement, right? But most of these SQL text examples are multiple statements. I didn't see anything in TestUtils for a series of statements, so I added a new helper accordingly with canonical strings, let me know if that covers it

Ah yeah a new helper sounds reasonable to me thanks!

iffyio · 2025-04-18T07:21:39Z

tests/sqlparser_mssql.rs

+    assert_eq!(stmts.len(), 2);
+    assert_eq!(stmts[1], Statement::Go(GoStatement { count: None }));
+
+    let comment_following_go = "USE some_database;\nGO -- okay";


maybe we can add a multine_line_comment_following_go test case? e.g. GO /* whitespace */ 42

iffyio · 2025-04-18T07:22:51Z

src/ast/mod.rs

+    ///
+    /// GO is not a Transact-SQL statement; it is a command recognized by various tools as a batch delimiter
+    ///
+    /// See <https://learn.microsoft.com/en-us/sql/t-sql/language-elements/sql-server-utilities-statements-go>


For visibility we can move the comment to the struct definition similar to the print statement?

This is already the same as print 🤔. Are you saying both comments should move to their respective structs?

Ah indeed, ideally both would have the doc comments on their respective structs, I think I meant to reference return statement in the other PR as the example

iffyio · 2025-04-18T07:39:00Z

src/dialect/mssql.rs

+        // - looking backwards there's only (any) whitespace preceded by a newline
+        // then: `GO` iSN'T a column alias
+        if kw == &Keyword::GO {
+            let mut look_back_count = 2;


double checking, why does the index start at 2 vs 1?

It's similar to parse_go, which references the existing previous token logic which also starts by subtracting 2. My understanding is that 0 is the next token, -1 is the current token, and -2 is the first previous token.

iffyio · 2025-04-18T07:39:27Z

src/dialect/mssql.rs

+        // then: `GO` iSN'T a column alias
+        if kw == &Keyword::GO {
+            let mut look_back_count = 2;
+            loop {


Can we have this logic as a helper function?

fn prev_nth_token_no_skip(&self, mut n: usize) -> Option<&TokenWithSpan> { // ... }

like a combination of peek_nth_token and prev_token

I added a new helper, done 👍

iffyio · 2025-04-19T07:00:31Z

src/test_utils.rs

@@ -166,6 +168,32 @@ impl TestedDialects {
        only_statement
    }

+    /// The same as [`one_statement_parses_to`] but it works for a multiple statements
+    pub fn multiple_statements_parse_to(


Suggested change

pub fn multiple_statements_parse_to(

pub fn statements_parse_to(

iffyio · 2025-04-19T07:01:00Z

tests/sqlparser_mssql.rs

+
+#[test]
+fn parse_mssql_go_keyword() {
+    let single_go_keyword = "USE some_database;\nGO";


Ah yeah a new helper sounds reasonable to me thanks!

iffyio · 2025-04-19T07:02:08Z

src/parser/mod.rs

@@ -4055,6 +4070,44 @@ impl<'a> Parser<'a> {
        )
    }

+    /// Look backwards in the token stream and expect that there was only whitespace tokens until the previous newline
+    pub fn expect_previously_only_whitespace_until_newline(&mut self) -> Result<(), ParserError> {


Suggested change

pub fn expect_previously_only_whitespace_until_newline(&mut self) -> Result<(), ParserError> {

pub(crate) fn expect_previously_only_whitespace_until_newline(&mut self) -> Result<(), ParserError> {

iffyio · 2025-04-19T07:06:58Z

src/parser/mod.rs

@@ -618,6 +632,7 @@ impl<'a> Parser<'a> {
                // `COMMENT` is snowflake specific https://docs.snowflake.com/en/sql-reference/sql/comment
                Keyword::COMMENT if self.dialect.supports_comment_on() => self.parse_comment(),
                Keyword::PRINT => self.parse_print(),
+                Keyword::GO => self.parse_go(),


can we rewind with self.prev_token() here before calling parse_go? so that the parse_go function is self contained and can parse a full GO statement. (I also realise now we missed that for print)

I see that some of the statement types in parse_statement are doing that but most aren't. What's the strategy on this? How do you know when you're supposed to do it or not?

Indeed the code is inconsistent in that regard historically, for newer statements ideally the parser functions are self contained when possible

Thanks, that makes sense. I've updated it to rewind before parsing (using raiserror as a reference)

iffyio · 2025-04-19T07:09:55Z

src/parser/mod.rs

+        self.expect_previously_only_whitespace_until_newline()?;
+
+        let count = loop {
+            // using this peek function because we want to halt this statement parsing upon newline


Can we include the example you had in the comment earlier, explicitly highlighting why this statement is special? I think otherwise it would not be obvious to folks that come across the code later on why the current code is a special case

Yes, I can add that comment. However there is also test coverage for this behavior, so it should be protected from future refactoring

iffyio · 2025-04-19T07:19:21Z

src/parser/mod.rs

@@ -15064,6 +15117,38 @@ impl<'a> Parser<'a> {
        }))
    }

+    /// Parse [Statement::Go]
+    fn parse_go(&mut self) -> Result<Statement, ParserError> {
+        self.expect_previously_only_whitespace_until_newline()?;


hmm this call look equivalent to the loop below that peeks forward to skip newlines? unclear why we're peeking backwards here right after we parsed the GO keyword (so that this will always be infallible?)

hmm this call look equivalent to the loop below that peeks forward to skip newlines? unclear why we're peeking backwards here right after we parsed the GO keyword (so that this will always be infallible?)

The too loops aren't the same. The reason we need to peek look backwards here is to forbid this syntax:

-- `GO` is disallowed select 1; go

If you actually run this on a real SQL Server instance, you will also get a similar error: Incorrect syntax near 'go'.. Therefore it seems prudent to forbid this syntax from parsing here in this library. This situation has test coverage with the invalid_go_position example.

Note that the extremely similar syntax select 1 go is allowed, but in this example go is a column alias rather than a batch delimiter.

Ah that makes sense! And the added comment clarifies as well thanks!

iffyio · 2025-04-19T07:20:34Z

src/dialect/mssql.rs

+                .expect_previously_only_whitespace_until_newline()
+                .is_ok()


if the intent is for the condition to return a bool, then we can update this function to return a bool instead of a result (where the latter is flagging an error to be handled)

In this case, it's most useful to know if there was previously only whitespace until a newline. However in the other call of this function in parse_go, we legitimately do want a parser error. Therefore we have choices:

expect_previously_only_whitespace_until_newline raises a parse error which makes sense in parse_go but is converted to a boolean here

expect_previously_only_whitespace_until_newline returns a boolean which makes sense here and then parse_go needs to separately raise a parse error

Which is the best choice for the time being?

Ah I see, 2. sounds desirable to return a boolean, in that the function is only checking if a condition holds, then interpretation of the condition is left to the caller of the function. in the other usage the caller does e.g.

if !self.prev_whitespace_only_is_newline() { return self.expected("newline ...") }

Gotcha, I will update it to do that

iffyio · 2025-04-19T07:25:06Z

src/parser/mod.rs

@@ -4055,6 +4070,44 @@ impl<'a> Parser<'a> {
        )
    }

+    /// Look backwards in the token stream and expect that there was only whitespace tokens until the previous newline
+    pub fn expect_previously_only_whitespace_until_newline(&mut self) -> Result<(), ParserError> {


hmm so i think it would be good to write this function in a reusable manner if possible since it feels similar to the peek_*, prev_* helper functions that we have. Would it be possible to introduce a generic prev_nth_token_no_skip(n: usize) that can be called by parser and dialect methods?

iffyio · 2025-04-23T16:17:24Z

src/parser/mod.rs

@@ -15064,6 +15117,38 @@ impl<'a> Parser<'a> {
        }))
    }

+    /// Parse [Statement::Go]
+    fn parse_go(&mut self) -> Result<Statement, ParserError> {
+        self.expect_previously_only_whitespace_until_newline()?;


Ah that makes sense! And the added comment clarifies as well thanks!

iffyio · 2025-04-23T16:23:20Z

src/parser/mod.rs

@@ -618,6 +632,7 @@ impl<'a> Parser<'a> {
                // `COMMENT` is snowflake specific https://docs.snowflake.com/en/sql-reference/sql/comment
                Keyword::COMMENT if self.dialect.supports_comment_on() => self.parse_comment(),
                Keyword::PRINT => self.parse_print(),
+                Keyword::GO => self.parse_go(),


Indeed the code is inconsistent in that regard historically, for newer statements ideally the parser functions are self contained when possible

iffyio · 2025-04-23T16:25:40Z

src/parser/mod.rs

+            expecting_statement_delimiter = match &statement {
+                Statement::If(s) => match &s.if_block.conditional_statements {
+                    // the `END` keyword doesn't need to be followed by a statement delimiter, so it shouldn't be expected here
+                    ConditionalStatements::BeginEnd { .. } => false,
+                    // parsing the statement sequence consumes the statement delimiter, so it shouldn't be expected here
+                    ConditionalStatements::Sequence { .. } => false,
+                },
+                // Treat batch delimiter as an end of statement, so no additional statement delimiter expected here


will this be replaced by similar solution as in #1808?

I suspect so... need to investigate. (I need to rebuild my mental model on this first 😆).

I've simplified this to reduce it down to only concerns within this PR 👍

iffyio · 2025-04-23T16:30:10Z

src/parser/mod.rs

+                    // special consideration required for single line comments since that string includes the newline
+                    Whitespace::SingleLineComment { comment, prefix: _ } => {
+                        if comment.ends_with('\n') {


double checking: is there a scenario where a single line comment doesn't end with a new line? spontaneously sounds like that should always hold true so that the manual newline check would not be required

double checking: is there a scenario where a single line comment doesn't end with a new line? spontaneously sounds like that should always hold true so that the manual newline check would not be required

I actually don't know, I was surprised to find that the newline is actually part of the comment text in this library. It seemed prudent to be defensive in this new code, since that comment parsing behavior maybe isn't particularly intentional.

iffyio · 2025-04-23T16:32:48Z

src/parser/mod.rs

@@ -3939,6 +3954,26 @@ impl<'a> Parser<'a> {
            })
    }

+    /// Return nth previous token, possibly whitespace
+    /// (or [`Token::EOF`] when before the beginning of the stream).
+    pub fn peek_prev_nth_token_no_skip(&self, n: usize) -> TokenWithSpan {


Suggested change

pub fn peek_prev_nth_token_no_skip(&self, n: usize) -> TokenWithSpan {

pub(crate) fn peek_prev_nth_token_no_skip(&self, n: usize) -> &TokenWithSpan {

we can probably start with the API being non-public. Then can we switch to returning a reference to avoid the mandatory cloning?

iffyio · 2025-04-23T16:38:54Z

src/dialect/mssql.rs

+                .expect_previously_only_whitespace_until_newline()
+                .is_ok()


Ah I see, 2. sounds desirable to return a boolean, in that the function is only checking if a condition holds, then interpretation of the condition is left to the caller of the function. in the other usage the caller does e.g.

if !self.prev_whitespace_only_is_newline() { return self.expected("newline ...") }

aharpervc · 2025-04-23T21:21:13Z

Here's another example case this PR should parse properly, before merging (on my todo list...)

USE some_database;
GO

;WITH cte AS (
  SELECT 1 x
)
SELECT *
FROM cte;

The peek logic in parse_go should be seeing that newline, but it's accidentally advancing past the whitespace, seeing the semi-colon, and failing.

Done 👍

- per documentation, "not a statement" but acts like one in all other regards - since it's a batch delimiter and statements can't extend beyond a batch, it also acts as a statement delimiter

- and use it for `expect_previously_only_whitespace_until_newline` so that can be simplified accordingly

…a bool - in `parse_go` we don't have a direct way to find what that previous non-whitespace token was, so the error message is adjusted accordingly

aharpervc marked this pull request as ready for review April 11, 2025 16:52

iffyio reviewed Apr 12, 2025

View reviewed changes

aharpervc force-pushed the mssql-go-keyword branch 2 times, most recently from 3dea67c to ea7db7d Compare April 14, 2025 15:19

aharpervc requested a review from iffyio April 14, 2025 15:23

aharpervc force-pushed the mssql-go-keyword branch 6 times, most recently from afe44a3 to fa964b5 Compare April 15, 2025 15:48

aharpervc commented Apr 15, 2025

View reviewed changes

src/parser/mod.rs Outdated Show resolved Hide resolved

aharpervc force-pushed the mssql-go-keyword branch 2 times, most recently from dc0bf6a to ed181fd Compare April 17, 2025 17:44

iffyio reviewed Apr 18, 2025

View reviewed changes

aharpervc force-pushed the mssql-go-keyword branch 6 times, most recently from 7689e0c to b8a184c Compare April 18, 2025 18:27

aharpervc requested a review from iffyio April 18, 2025 18:30

iffyio reviewed Apr 19, 2025

View reviewed changes

aharpervc force-pushed the mssql-go-keyword branch from f3cbaa1 to 80591f1 Compare April 21, 2025 18:00

aharpervc requested a review from iffyio April 21, 2025 21:40

iffyio reviewed Apr 23, 2025

View reviewed changes

aharpervc added 2 commits April 23, 2025 17:40

Add support for GO batch delimiter in SQL Server

25fd849

- per documentation, "not a statement" but acts like one in all other regards - since it's a batch delimiter and statements can't extend beyond a batch, it also acts as a statement delimiter

Enable GO to terminate an IF statement

24d813b

aharpervc added 11 commits April 23, 2025 17:40

Simplify logic to have GO terminate a statement

f4750f0

Fix not treating GO as a statement delimiter next to a query

3db7fba

Fix failing to parse GO after a comment

ca0bb28

Add additional multi line comment test

94abfb7

Add helper to simplify tests & add canonical string

cfecd33

Extract common logic to look back for a newline to a helper

2b28275

Rename multiple_statements_parse_to -> statements_parse_to

bc55f6f

Introduce peek_prev_nth_token_no_skip helper

d2b15df

- and use it for `expect_previously_only_whitespace_until_newline` so that can be simplified accordingly

Add clarification for whitespace sensitivity parsing GO

827dfe7

Fix GO failing to find following newline

1c01035

Make peek_prev_nth_token_no_skip -> _ref, reduce visibility to crate

b46fefc

aharpervc force-pushed the mssql-go-keyword branch from b56ae20 to b46fefc Compare April 23, 2025 21:42

aharpervc added 2 commits April 23, 2025 17:56

Refactor expect_previously_only_whitespace_until_newline to return …

7863bef

…a bool - in `parse_go` we don't have a direct way to find what that previous non-whitespace token was, so the error message is adjusted accordingly

Rewind the current token before parse_go

6726d42

aharpervc force-pushed the mssql-go-keyword branch from 5972d59 to 6726d42 Compare April 23, 2025 22:03

Revert unnecessary conditional logic

fb41bfc

aharpervc requested a review from iffyio April 23, 2025 22:13

	Keyword::GO if dialect_of!(self is MsSqlDialect) => {
	Keyword::GO => {

	fn parse_go(&mut self) -> Result<Statement, ParserError> {
	/// Parse [Statement::Go]
	fn parse_go(&mut self) -> Result<Statement, ParserError> {

	pub fn multiple_statements_parse_to(
	pub fn statements_parse_to(

	pub fn expect_previously_only_whitespace_until_newline(&mut self) -> Result<(), ParserError> {
	pub(crate) fn expect_previously_only_whitespace_until_newline(&mut self) -> Result<(), ParserError> {

	pub fn peek_prev_nth_token_no_skip(&self, n: usize) -> TokenWithSpan {
	pub(crate) fn peek_prev_nth_token_no_skip(&self, n: usize) -> &TokenWithSpan {

Add support for GO batch delimiter in SQL Server #1809

Are you sure you want to change the base?

Add support for GO batch delimiter in SQL Server #1809

Conversation

aharpervc commented Apr 11, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

aharpervc Apr 14, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

aharpervc Apr 14, 2025 • edited Loading

Choose a reason for hiding this comment

aharpervc commented Apr 15, 2025

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

aharpervc Apr 21, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

aharpervc commented Apr 23, 2025 • edited Loading

Add support for `GO` batch delimiter in SQL Server #1809

Add support for `GO` batch delimiter in SQL Server #1809

aharpervc commented Apr 11, 2025 •

edited

Loading

aharpervc Apr 14, 2025 •

edited

Loading

aharpervc Apr 14, 2025 •

edited

Loading

aharpervc Apr 21, 2025 •

edited

Loading

aharpervc commented Apr 23, 2025 •

edited

Loading