924060929 commented on PR #67438: URL: https://github.com/apache/doris/pull/67438#issuecomment-5507735902
The intended precedence is correct: for a multipart name such as `a.b`, Doris should first preserve the historical `relation_alias.column` interpretation, and only fall back to `column.nested_field` after no visible relation qualifier can bind it. The old all-in-one current-scope lookup must therefore change; otherwise an unrelated inner column named `a` can hide an outer relation alias `a`, causing either an analysis error or a silent wrong binding. The remaining issue is not that relation-qualified lookup is prioritized, but that the new prepass assumes `getScope()` is every analyzer's complete local lookup scope: ```text bind relation in getScope() bind relation in outerScope bindSlotByThisScope() ``` That assumption does not hold for analyzers such as HAVING/QUALIFY, where `bindSlotByThisScope()` is overridden to search additional local scopes. In those analyzers, a valid inner binding can be skipped and an outer relation can win prematurely. I suggest making the relation-only phase follow the same analyzer-specific local lookup policy as the full binding phase, for example with a protected `bindSlotByRelationQualifierInThisScope()` hook parallel to `bindSlotByThisScope()`. Custom binders can then override it using the same local scope order. The intended contract would be: ```text 1. explicit lexical/local bindings that must shadow outer names 2. relation-qualified lookup across the analyzer's complete local scope policy 3. relation-qualified lookup in the outer query scope 4. local nested-field fallback using the same complete local scope policy 5. outer nested-field fallback ``` This keeps the compatibility fix while avoiding special-case regressions caused by bypassing custom local binders. Please also add a reused-alias HAVING/QUALIFY test so the scope contract is fixed by coverage rather than by the current implementation shape. -- 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]
