You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tajo.apache.org by "Keuntae Park (JIRA)" <ji...@apache.org> on 2014/01/22 04:10:19 UTC
[jira] [Updated] (TAJO-542) Tajo group by bnf grammar is different
from SQL 2003
[ https://issues.apache.org/jira/browse/TAJO-542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Keuntae Park updated TAJO-542:
------------------------------
Description:
BNF grammar of Tajo about 7.9 <group by clause> is different from SQL 2003.
It does not make problem now.
But, if Tajo becomes to support using non-reserved keyword as Identifier (TAJO-497),
this may be a problem.
For example, if group by clause contains column and cube() like
{noformat}
group by col1, col2, cube(col3, col4)
{noformat}
Currently, when Tajo parser met a column (which is defined as ordinary_grouping_set), it greedily checks if comma separated according words can be included in the same ordinary_grouping_set also.
So, after TAJO-497, non reserved keywords, in this case 'cube', will be always treated as ordinary_grouping_set even if it can be used as both column name and keyword.
Differently, ordinary_grouping_set of SQL 2003 has only one item if not enclosed by parenthesis, which means that it does not check following comma separated words,
so 'cube' can be parsed as cube_list correctly.
I think this issue's related with TAJO-541 also.
was:
BNF grammar of Tajo about 7.9 <group by clause> is different from SQL 2003.
It does not make problem now.
But, if Tajo becomes to support using non-reserved keyword as Identifier (TAJO-497),
this may be a problem.
For example, if group by clause contains column and cube() like
{noformat}
group by col1, col2, cube(col3, col4)
{noformat}
Currently, when Tajo parser met a column defined as ordinary_grouping_set, it greedily checks if comma separated according words can be included in the same ordinary_grouping_set also.
So, after TAJO-497, non reserved keywords, in this case 'cube', will be always treated as ordinary_grouping_set even if it can be used as both column name and keyword.
Differently, ordinary_grouping_set of SQL 2003 has only one item if not enclosed by parenthesis, which means that it does not check following comma separated words,
so 'cube' can be parsed as cube_list correctly.
I think this issue's related with TAJO-541 also.
> Tajo group by bnf grammar is different from SQL 2003
> ----------------------------------------------------
>
> Key: TAJO-542
> URL: https://issues.apache.org/jira/browse/TAJO-542
> Project: Tajo
> Issue Type: Bug
> Reporter: Keuntae Park
>
> BNF grammar of Tajo about 7.9 <group by clause> is different from SQL 2003.
> It does not make problem now.
> But, if Tajo becomes to support using non-reserved keyword as Identifier (TAJO-497),
> this may be a problem.
> For example, if group by clause contains column and cube() like
> {noformat}
> group by col1, col2, cube(col3, col4)
> {noformat}
> Currently, when Tajo parser met a column (which is defined as ordinary_grouping_set), it greedily checks if comma separated according words can be included in the same ordinary_grouping_set also.
> So, after TAJO-497, non reserved keywords, in this case 'cube', will be always treated as ordinary_grouping_set even if it can be used as both column name and keyword.
> Differently, ordinary_grouping_set of SQL 2003 has only one item if not enclosed by parenthesis, which means that it does not check following comma separated words,
> so 'cube' can be parsed as cube_list correctly.
> I think this issue's related with TAJO-541 also.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)