[
https://issues.apache.org/jira/browse/CALCITE-7881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Darpan Lunagariya (e6data) updated CALCITE-7881:
------------------------------------------------
Description:
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.
was:
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?
> 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)
> 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)
