Doris-Breakwater commented on issue #66041:
URL: https://github.com/apache/doris/issues/66041#issuecomment-5077822722

   Breakwater-GitHub-Analysis-Slot: slot_5d2be5e6b388
   
   ### Initial assessment
   
   Confirmed as a genuine FE/Nereids column-binding bug. The reported mechanism 
is present in both current `master` and `branch-4.0`.
   
   The relevant path is:
   
   1. `BindRelation` parses an enabled Hive view into a `LogicalView`, then 
wraps it in `new LogicalSubQueryAlias<>(qualifiedTableName, hiveViewPlan)`.
   2. `LogicalView.computeOutput()` attaches the declared view column as 
one-level metadata, but 
`SlotReference.withOneLevelTableAndColumnAndQualifier()` deliberately preserves 
the slot's existing `name`. Thus a body such as `SELECT 1 AS a, 2 AS b` still 
exposes slot names `a, b` at this point even when the HMS schema is `col1, 
col2`.
   3. The two-argument `LogicalSubQueryAlias` constructor leaves 
`columnAliases` empty. `computeOutputInternal()` consequently falls back to 
those child names, so the outer binder cannot resolve `col1` or `col2`.
   
   This is deterministic and does not require runtime logs or a query profile 
to establish. The impact is an analysis failure for HMS views whose declared 
names differ from their view-body output names; `SELECT *` can mask the binding 
failure, while explicit references to the declared names fail. There is no 
indication of data corruption.
   
   The issue currently has no labels. Suggested triage is an FE/Nereids 
external-catalog correctness bug.
   
   ### Fix assessment
   
   The implementation direction in #66042 is correct: derive the aliases 
positionally from `HMSExternalTable.getFullSchema()` and pass them to the 
three-argument `LogicalSubQueryAlias` constructor. That constructor already 
preserves the child expression IDs and types while replacing the exposed names, 
which restores the Hive view's declared output contract.
   
   One edge case should be handled deliberately before merge: 
`HMSExternalTable.getFullSchema()` can return `null` when the schema cache has 
no value, and `LogicalView.computeOutput()` currently tolerates null/empty 
schemas. Calling `.stream()` unconditionally in the new path would turn that 
condition into an NPE. Please preserve the existing fallback behavior or emit 
an intentional user-facing analysis error.
   
   ### Missing information
   
   No additional reporter information is required to confirm the root cause. 
For release/backport tracking only, the exact affected 4.0 maintenance build or 
commit would be useful.
   
   I did not independently run the FE unit test locally because the 
repository's required `thirdparty/installed/bin/protoc` executable is absent; 
the conclusion above is based on direct inspection of the affected code on both 
branches. The PR reports a focused `BindRelationTest` passing locally.
   
   ### Recommended next steps
   
   1. Review #66042 with the null/empty-schema case addressed.
   2. Keep the focused alias-output assertion and add an analyzer-level 
assertion for `SELECT col1, col2 FROM ...`; also verify that `SELECT a, b FROM 
...` is rejected so the declared schema remains the sole public contract.
   3. Verify `SELECT *` exposes `col1, col2` and retains the expected view 
column metadata.
   4. After the master fix is validated, backport it to the supported 4.0 
branch.
   5. Audit the Iceberg-view branch in the same `BindRelation` switch: it also 
wraps `parseAndAnalyzeExternalView(...)` with the two-argument 
`LogicalSubQueryAlias` constructor and may have the same issue if Iceberg 
declared view names can diverge from body slot names.
   


-- 
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]

Reply via email to