[SPARK-39259][SQL][FOLLOWUP] Fix source and binary incompatibilities in transformDownWithSubqueries #36765
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What changes were proposed in this pull request?
This is a followup to #36654. That PR modified the existing
QueryPlan.transformDownWithSubqueries
to add additional arguments for tree pattern pruning.In this PR, I roll back the change to that method's signature and instead add a new
transformDownWithSubqueriesAndPruning
method.Why are the changes needed?
The original change breaks binary and source compatibility in Catalyst. Technically speaking, Catalyst APIs are considered internal to Spark and are subject to change between minor releases (see source), but I think it's nice to try to avoid API breakage when possible.
While trying to compile some custom Catalyst code, I ran into issues when trying to call the
transformDownWithSubqueries
method without supplying a tree pattern filter condition. If I dotransformDownWithSubqueries() { f }
then I get a compilation error. I think this is due to the first parameter group containing all default parameters.My PR's solution of adding a new
transformDownWithSubqueriesAndPruning
method solves this problem. It's also more consistent with the naming convention used for other pruning-enabled tree transformation methods.Does this PR introduce any user-facing change?
No.
How was this patch tested?
Existing tests.