[jira] [Commented] (CALCITE-3811) JDBC adapter generates SQL with invalid field names if Filter's row type is different from its input

["Danny Chen (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CALCITE-3811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17041526#comment-17041526 ] 

Danny Chen commented on CALCITE-3811:
-------------------------------------

Is this issue going to be included in 1.22.0 ?

> JDBC adapter generates SQL with invalid field names if Filter's row type is different from its input
> ----------------------------------------------------------------------------------------------------
>
>                 Key: CALCITE-3811
>                 URL: https://issues.apache.org/jira/browse/CALCITE-3811
>             Project: Calcite
>          Issue Type: Bug
>          Components: jdbc-adapter
>    Affects Versions: 1.21.0
>            Reporter: Julian Hyde
>            Assignee: Julian Hyde
>            Priority: Major
>             Fix For: 1.22.0
>
>
> JDBC adapter generates SQL with invalid field names if a {{Filter}} object's row type is different from its input. Usually a {{Filter}} object's row type is identical to its input's row type (because that is how it derives its row type on construction), but if you call {{RelNode.replaceInput}} after construction it is possible to make the field names inconsistent.
> Here is an example of the wrong SQL generated:
> {code}
> SELECT D AS `emps.deptno`
> FROM (
>   SELECT DEPTNO AS D2, COUNT(*) AS `emps.count`
>   FROM `scott`.EMP
>   GROUP BY DEPTNO
>   HAVING COUNT(*) < 2) AS `t1`
> {code}
> Note that the sub-query returns a column {{D2}} but the outer {{SELECT}} expression refers to {{D}}, because that was the name in the row type of the {{Filter}} (which became the {{HAVING}} clause in the generated SQL).



--
This message was sent by Atlassian Jira
(v8.3.4#803005)