[
https://issues.apache.org/jira/browse/CALCITE-7679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
DongShengHe updated CALCITE-7679:
---------------------------------
Description:
h3. Description
{{RelToSqlConverter}} may generate a literal in the {{GROUP BY}} clause for
dialects that do not support them when the grouping expression is hidden behind
multiple {{Project}} nodes.
This is related to CALCITE-4702. Its fix uses
{{AggregateProjectConstantToDummyJoinRule}} for dialects that do not support
grouping by literals. However, the rule only examines the {{Project}} directly
below the {{{}Aggregate{}}}.
For example, consider the following relational plan:
{code:java}
LogicalAggregate(group=[{0}])
LogicalProject(ID=[$0])
LogicalProject(ID=[null:NULL])
LogicalTableScan(table=[[hr, emps]]) {code}
The direct project expression is {{{}$0{}}}, so
{{AggregateProjectConstantToDummyJoinRule}} does not recognize it as a literal.
As a result, the PostgreSQL dialect generates:
{code:java}
SELECT NULL AS "ID"
FROM "hr"."emps"
GROUP BY NULL {code}
was:
h3. Description
{{RelToSqlConverter}} may generate a literal in the {{GROUP BY}} clause for
dialects that do not support them when the grouping expression is hidden behind
multiple {{Project}} nodes.
This is related to CALCITE-4702. Its fix uses
{{AggregateProjectConstantToDummyJoinRule}} for dialects that do not support
grouping by literals. However, the rule only examines the {{Project}} directly
below the {{{}Aggregate{}}}.
For example, consider the following relational plan:
{code:java}
LogicalAggregate(group=[{0}])
LogicalProject(ID=[$0])
LogicalProject(ID=[null:NULL])
LogicalTableScan(table=[[hr, emps]]) {code}
{{{}{}}}{{{}{}}}
The direct project expression is {{{}$0{}}}, so
{{AggregateProjectConstantToDummyJoinRule}} does not recognize it as a literal.
As a result, the PostgreSQL dialect generates:
{code:java}
SELECT NULL AS "ID"
FROM "hr"."emps"
GROUP BY NULL {code}
{{}}
> RelToSqlConverter generates GROUP BY literals for dialects that do not
> support them when the constant is hidden by nested Projects
> ----------------------------------------------------------------------------------------------------------------------------------
>
> Key: CALCITE-7679
> URL: https://issues.apache.org/jira/browse/CALCITE-7679
> Project: Calcite
> Issue Type: Bug
> Reporter: DongShengHe
> Priority: Minor
>
> h3. Description
> {{RelToSqlConverter}} may generate a literal in the {{GROUP BY}} clause for
> dialects that do not support them when the grouping expression is hidden
> behind multiple {{Project}} nodes.
> This is related to CALCITE-4702. Its fix uses
> {{AggregateProjectConstantToDummyJoinRule}} for dialects that do not support
> grouping by literals. However, the rule only examines the {{Project}}
> directly below the {{{}Aggregate{}}}.
>
> For example, consider the following relational plan:
> {code:java}
> LogicalAggregate(group=[{0}])
> LogicalProject(ID=[$0])
> LogicalProject(ID=[null:NULL])
> LogicalTableScan(table=[[hr, emps]]) {code}
>
> The direct project expression is {{{}$0{}}}, so
> {{AggregateProjectConstantToDummyJoinRule}} does not recognize it as a
> literal.
> As a result, the PostgreSQL dialect generates:
>
> {code:java}
> SELECT NULL AS "ID"
> FROM "hr"."emps"
> GROUP BY NULL {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
