Darpan Lunagariya (e6data) created CALCITE-7881:
---------------------------------------------------
Summary: 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
Reporter: Darpan Lunagariya (e6data)
h2. Incorrect column resolution depending on schema and alias names
This reproduces using the existing {{SALES.EMP}} table in the default
{{SqlToRelConverterTest}} catalog. No schema or table creation is required.
{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.
Could the community clarify the intended resolution precedence and whether
these speculative catalog lookups can be avoided?
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
