tajo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Keuntae Park (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (TAJO-542) Tajo group by bnf grammar is different from SQL 2003
Date Wed, 22 Jan 2014 03:10:19 GMT

     [ 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)

Mime
View raw message