miland-db commented on code in PR #49427:
URL: https://github.com/apache/spark/pull/49427#discussion_r1938492586
##########
sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/plans/logical/SqlScriptingLogicalPlans.scala:
##########
@@ -298,3 +307,100 @@ case class ForStatement(
ForStatement(query, variableName, body, label)
}
}
+
+/**
+ * Logical operator for an error condition.
+ * @param conditionName Name of the error condition.
+ * @param sqlState SQLSTATE or Error Code.
+ */
+case class ErrorCondition(
+ conditionName: String,
+ sqlState: String) extends CompoundPlanStatement {
Review Comment:
When I think about this, `ErrorCondition` is in a way a
`CompoundPlanStatement` because we use it to declare condition and store the
details there. In `visitCompoundStatementImpl` we are returning
`CompoundPlanStatement` and `ErrorCondition` is one of them (also in the parser
rule).
Looking at this, ErrorCondition (or DeclareConditionStatement) can either
extend single statement, or we can leave it as it is now. What's your opinion
@cloud-fan?
--
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: reviews-unsubscr...@spark.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: reviews-unsubscr...@spark.apache.org
For additional commands, e-mail: reviews-h...@spark.apache.org
