davidm-db commented on code in PR #47609:
URL: https://github.com/apache/spark/pull/47609#discussion_r1704256694
##########
sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/plans/logical/SqlScriptingLogicalPlans.scala:
##########
@@ -15,37 +15,40 @@
* limitations under the License.
*/
-package org.apache.spark.sql.catalyst.parser
+package org.apache.spark.sql.catalyst.plans.logical
-import org.apache.spark.sql.catalyst.plans.logical.LogicalPlan
-import org.apache.spark.sql.catalyst.trees.{CurrentOrigin, Origin, WithOrigin}
+import org.apache.spark.sql.catalyst.expressions.Attribute
/**
* Trait for all SQL Scripting logical operators that are product of parsing
phase.
* These operators will be used by the SQL Scripting interpreter to generate
execution nodes.
*/
-sealed trait CompoundPlanStatement
+sealed trait CompoundPlanStatement extends LogicalPlan
Review Comment:
`CompoundBody` is logical plan by default (by extending `Command`) and that
is enough for proper script execution. Should we have other logical components
extending `LogicalPlan` (as it is now) or shouldn't we complicate and remove
this dependency? There seems to be no need to have every operator extending
`LogicalPlan` - `CompoundBody` needs to because we need to be able to process
it in multiple places in code, but all the other operators from this file are
processed by Interpreter only!
--
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
