pan3793 commented on code in PR #58661: URL: https://github.com/apache/spark/pull/58661#discussion_r3999985641
########## sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/plans/logical/cteOperators.scala: ########## @@ -112,6 +112,9 @@ case class UnionLoopRef( * @param underSubquery If true, it means we don't need to add a shuffle for this CTE relation as * subquery reuse will be applied to reuse CTE relation output. * @param maxDepth The maximal depth of a recursion in a recursive CTE. + * @param materialized The user-specified materialization option: `Some(true)` for `MATERIALIZED`, Review Comment: They overlap on "never inline" but the code relies on three differences. `materialized` is tri-state: `NOT MATERIALIZED` needs the `Some(false)` arm in `InlineCTE.shouldInline`. `alwaysInline` mode still inlines a `MATERIALIZED` CTE so `CheckAnalysis` keeps the original plan shape, while `forceSkipInline` overrides even that. And a `MATERIALIZED` CTE that cannot be materialized gets a user-facing analysis error, while a `forceSkipInline` violation is an `INTERNAL_ERROR`, since SPARK-58006's producer controls the definition and plans a partitioning field beside the flag. Folding them together would need a provenance bit to keep those apart, so the two fields stay. -- 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]
