You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@calcite.apache.org by "Leonid Chistov (Jira)" <ji...@apache.org> on 2022/12/01 16:42:00 UTC

[jira] [Updated] (CALCITE-5412) ROLLUP/CUBE non-standard syntax support logic is buggy

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

Leonid Chistov updated CALCITE-5412:
------------------------------------
    Description: 
There are currently several dialects supported by Calcite which share a logic of using 'GROUP BY ... WITH ROLLUP' or 'GROUP BY ... WITH CUBE' syntax instead of 'GROUP BY ROLLUP(...)' and 'GROUP BY CUBE(...)' syntax: MySQL5, MsSQL, Hive and Spark.

Note: actually Spark should not be on this list anymore, see https://issues.apache.org/jira/browse/CALCITE-5411

Following issues exist regarding current implementation of this logic:
 * There is a bug in 'Result RelToSqlConverter::visit(Sort e)' method. Check 'hasTrickyRollup' does not take into account possibility of different order of fields in 'ROLLUP' clause and 'ORDER BY' clause. Because of this, we loose information about order of fields in 'ORDER BY' clause in the conversion under this check.
 * CUBE clause seems to be not supported in MYSQL5.x in any form ([https://dev.mysql.com/doc/refman/5.7/en/group-by-modifiers.html]), but we don’t check it. 
 * We don't have an check for the “GROUP BY GROUPING SETS(...)” syntax support, thus we always generate SQL code for such clause, is it was supported

  was:
There are currently several dialects supported by Calcite which share a logic of using 'GROUP BY ... WITH ROLLUP' or 'GROUP BY ... WITH CUBE' syntax instead of 'GROUP BY ROLLUP(...)' and 'GROUP BY CUBE(...)' syntax: MySQL5, MsSQL, Hive and Spark.

Note: actually Spark should not be on this list anymore, see https://issues.apache.org/jira/browse/CALCITE-5411

Following issues exist regarding current implementation of this logic:
 * There is a bug in Result RelToSqlConverter::visit(Sort e). Check 'hasTrickyRollup' does not take into account possibility of different order of fields in 'ROLLUP' clause and 'ORDER BY' clause. Because of this, we loose information about order of fields in 'ORDER BY' clause in the conversion under this check.
 * CUBE clause seems to be not supported in MYSQL5.x in any form ([https://dev.mysql.com/doc/refman/5.7/en/group-by-modifiers.html]), but we don’t check it. 
 * We don't have an check for the “GROUP BY GROUPING SETS(...)” syntax support, thus we always generate SQL code for such clause, is it was supported


> ROLLUP/CUBE non-standard syntax support logic is buggy
> ------------------------------------------------------
>
>                 Key: CALCITE-5412
>                 URL: https://issues.apache.org/jira/browse/CALCITE-5412
>             Project: Calcite
>          Issue Type: Bug
>    Affects Versions: 1.32.0
>            Reporter: Leonid Chistov
>            Priority: Minor
>
> There are currently several dialects supported by Calcite which share a logic of using 'GROUP BY ... WITH ROLLUP' or 'GROUP BY ... WITH CUBE' syntax instead of 'GROUP BY ROLLUP(...)' and 'GROUP BY CUBE(...)' syntax: MySQL5, MsSQL, Hive and Spark.
> Note: actually Spark should not be on this list anymore, see https://issues.apache.org/jira/browse/CALCITE-5411
> Following issues exist regarding current implementation of this logic:
>  * There is a bug in 'Result RelToSqlConverter::visit(Sort e)' method. Check 'hasTrickyRollup' does not take into account possibility of different order of fields in 'ROLLUP' clause and 'ORDER BY' clause. Because of this, we loose information about order of fields in 'ORDER BY' clause in the conversion under this check.
>  * CUBE clause seems to be not supported in MYSQL5.x in any form ([https://dev.mysql.com/doc/refman/5.7/en/group-by-modifiers.html]), but we don’t check it. 
>  * We don't have an check for the “GROUP BY GROUPING SETS(...)” syntax support, thus we always generate SQL code for such clause, is it was supported



--
This message was sent by Atlassian Jira
(v8.20.10#820010)