haoyangeng-db opened a new pull request, #56024: URL: https://github.com/apache/spark/pull/56024
### What changes were proposed in this pull request? This is a follow-up to SPARK-46625 (PR #55949 - "Place IDENTIFIER placeholder in command name slot"). SPARK-46625 moved `PlanWithUnresolvedIdentifier` from wrapping the whole command into the command's identifier slot at parse time. For `InsertIntoStatement` and `V2WriteCommand` the placeholder now lives in `.table`, which is a non-child `LogicalPlan` slot (`override def child = query`). That PR correctly added explicit recursion for that slot in `BindParameters` (parameter binding) and `ResolveIdentifierClause` (materializing the placeholder once `identifierExpr` is resolved), but the same recursion was missing from `ResolveReferences`, which owns column / variable resolution. This PR adds two cases at the top of `ResolveReferences.doApply` that mirror the existing pattern: when `InsertIntoStatement.table` or `V2WriteCommand.table` is an unresolved `PlanWithUnresolvedIdentifier`, resolve `identifierExpr` via `resolveExpressionByPlanChildren(..., includeLastResort = true)` (which runs the resolveColsLastResort` path: `resolveVariables compose resolveOuterRef`). The `!identifierExpr.resolved` guard keeps the cases idempotent under bottom-up traversal. ### Why are the changes needed? Without this, `INSERT INTO IDENTIFIER(<sql-variable>) ...` fails analysis: the `UnresolvedAttribute` for the variable name sitting inside `PlanWithUnresolvedIdentifier.identifierExpr` is never rewritten to a `VariableReference`. Since `ResolveIdentifierClause` only fires when `identifierExpr.resolved && childrenResolved`, the placeholder never materializes; the plan reaches `PreprocessTableInsertion` with an unresolved attribute and errors out (e.g. `UNSUPPORTED_INSERT.RDD_BASED`). Repro on master before this fix: ```sql CREATE TABLE t (a INT) USING PARQUET; DECLARE OR REPLACE VARIABLE target_table STRING; SET VAR target_table = 't'; INSERT INTO IDENTIFIER(target_table) SELECT 42 AS a; ``` The same shape applies to `OverwriteByExpression.table` (e.g. `REPLACE WHERE`, `REPLACE ON`, `REPLACE USING` variants of INSERT) - fixed by the same `V2WriteCommand` case. ### Does this PR introduce _any_ user-facing change? No. Bug-fix only. ### How was this patch tested? New test added. ### Was this patch authored or co-authored using generative AI tooling? Co-authored with Claude Code. -- 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]
