[jira] [Updated] (CALCITE-4090) When generating SQL for DB2, a complex SELECT above a sub-query generates a bad table alias

["Julian Hyde (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CALCITE-4090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Julian Hyde updated CALCITE-4090:
---------------------------------
    Affects Version/s: 1.23.0
              Summary: When generating SQL for DB2, a complex SELECT above a sub-query generates a bad table alias  (was: DB2 aliasing breaks with a complex select above a subselect)

> When generating SQL for DB2, a complex SELECT above a sub-query generates a bad table alias
> -------------------------------------------------------------------------------------------
>
>                 Key: CALCITE-4090
>                 URL: https://issues.apache.org/jira/browse/CALCITE-4090
>             Project: Calcite
>          Issue Type: Bug
>    Affects Versions: 1.23.0
>            Reporter: Steven Talbot
>            Assignee: Julian Hyde
>            Priority: Major
>             Fix For: 1.24.0
>
>
> Test in RelToSqlConverterTest:
> {code:java}
> @Test void testDb2DialectSubselect() {
>   String query = "select count(foo), \"units_per_case\" "
>       + "from (select \"units_per_case\", \"cases_per_pallet\", \"product_id\", 1 as foo from \"product\") where \"cases_per_pallet\" > 100 "
>       + "group by \"product_id\", \"units_per_case\" "
>       + "order by \"units_per_case\" desc";
>   final String expected = "SELECT COUNT(*), t.units_per_case\n" +
>       "FROM (SELECT product.units_per_case, product.cases_per_pallet, product.product_id, 1 AS " +
>       "FOO\n" +
>       "FROM foodmart.product AS product) AS t\n" +
>       "WHERE t.cases_per_pallet > 100\n" +
>       "GROUP BY t.product_id, t.units_per_case\n" +
>       "ORDER BY t.units_per_case DESC";
>   sql(query).withDb2().ok(expected);
> }
> {code}
> The test fails with the "t." alias qualifier in the group by/order by/main select actually being "t0.". 
> From stepping through the code in the debugger, I believe this is a general problem with the way aliases are calculated in situations like this by SqlImplementor, but other dialects with hasImplicitTableAlias() do not force qualified contexts and therefore do not hit this.



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