[
https://issues.apache.org/jira/browse/CALCITE-7881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Darpan Lunagariya (e6data) updated CALCITE-7881:
------------------------------------------------
Affects Version/s: 1.42.0
> Struct field references can resolve to another table and cause unnecessary
> catalog lookups
> ------------------------------------------------------------------------------------------
>
> Key: CALCITE-7881
> URL: https://issues.apache.org/jira/browse/CALCITE-7881
> Project: Calcite
> Issue Type: Bug
> Affects Versions: 1.42.0
> Reporter: Darpan Lunagariya (e6data)
> Priority: Major
>
> h2. Incorrect column resolution depending on schema and alias names
> Reproduction SQL:
> {code:sql}
> WITH input_data AS (
> SELECT CAST(ROW(-1) AS ROW(empno INTEGER)) AS emp
> )
> SELECT sales.emp.empno
> FROM input_data AS sales
> CROSS JOIN sales.emp AS emp;
> {code}
> The intended reference is the struct field from alias {{sales}}, containing
> {{-1}}. However, Calcite produces:
> {code}
> LogicalProject(EMPNO=[$1])
> LogicalJoin(condition=[true], joinType=[inner])
> LogicalValues(tuples=[[{ -1 }]])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> {code}
> The projection selects {{$1}}, the existing table's {{EMPNO}}, instead of
> {{$0}}, the constant struct field.
> Changing only the final alias from {{AS emp}} to {{AS e}} changes the
> projection to {{EMPNO=[$0]}}. Both plans were verified.
> h2. Unnecessary catalog lookups even when resolution is correct
> The incorrect binding depends on the schema/table/alias names. Even when the
> catalog lookup does not match the joined table and Calcite eventually
> resolves the struct field correctly, {{ListScope.findChild}} still performs
> the speculative catalog lookup before falling back to the shorter alias
> prefix. These repeated lookups add validation work and can increase latency
> when catalog access requires external metadata calls.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
