cloud-fan commented on code in PR #58530:
URL: https://github.com/apache/spark/pull/58530#discussion_r3945872256
##########
sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/parser/SqlStatementSplitter.scala:
##########
@@ -253,17 +312,13 @@ object SqlStatementSplitter {
stopInner = true
} else if (token.getType == SqlBaseLexer.SEMICOLON) {
if (bufferHasContent) {
- val stmt = buffer.toString.trim
- if (stmt.nonEmpty) {
- completeStatements += SqlStatement(stmt, token.getText)
- }
+ positionedStatement(token.getText).foreach(completeStatements
+= _)
Review Comment:
**Blocking (P1):** When validation of a balanced `BEGIN ... END` candidate
fails inside the body, this fallback stops at the first internal semicolon. As
the new golden output demonstrates, `parse_sql('BEGIN SELECT 1; SELEC 2; END')`
then emits three top-level elements and reports bogus incomplete-BEGIN and
bare-END errors instead of one error for the submitted compound statement.
Please preserve the enclosing compound boundary during malformed-body recovery,
then add a focused malformed-block-plus-following-statement regression and
regenerate the SQL golden output.
**Recommended change:** Preserve a syntactically delimited outer BEGIN ...
END region as one batch segment even when validation fails inside its body, and
resume top-level splitting only after that region.
**Why this works:** Make SqlStatementSplitter's FailedNonEof recovery
compound-aware: retain the matching outer END boundary for a balanced compound
candidate, pass the complete segment to ParseSqlResult for one error object,
and keep the existing single-delimiter fallback for ordinary invalid statements
and unsupported grammar extensions.
**Scope:** SqlStatementSplitter malformed-compound recovery, a focused
ParseSqlResultSuite regression, and regenerated parse_sql SQL golden output.
**Compatibility:** This restores the documented
one-object-per-top-level-statement behavior for balanced malformed compounds
while preserving existing ordinary-invalid, extension-fallback, valid-compound,
and unclosed-partial behavior.
**Risks:** Compound-aware recovery must not consume a following top-level
statement or reinterpret an unclosed BEGIN block as complete.
**Constraints:** Keep the existing fallback behavior for ordinary invalid
statements and parser extensions. Regenerate generated SQL golden files through
SQLQueryTestSuite rather than editing them directly.
**Success:** A balanced BEGIN ... END block with an invalid inner statement
followed by SELECT 3 produces exactly two parse_sql results: one failed object
spanning the complete compound statement and one successful SELECT object with
the correct source span.
--
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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
