[ https://issues.apache.org/jira/browse/ASTERIXDB-2601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16874550#comment-16874550 ]
Dmitry Lychagin commented on ASTERIXDB-2601: -------------------------------------------- You're right. The rewriting adds GROUP ALL clause in this case which introduces a new variable scope. This new scope does not contain 'a' variable, hence the error message. Agreed, that the error message needs to be improved. > Misleading/perplexing aggregate-related error message > ----------------------------------------------------- > > Key: ASTERIXDB-2601 > URL: https://issues.apache.org/jira/browse/ASTERIXDB-2601 > Project: Apache AsterixDB > Issue Type: Bug > Components: *DB - AsterixDB, SQL - Translator SQL++ > Affects Versions: 0.9.4.1 > Reporter: Michael J. Carey > Assignee: Dmitry Lychagin > Priority: Major > Fix For: 0.9.5 > > > The following illegal aggregate query has a confusing error message that > leaves the user having no idea what's wrong: > SELECT a.handle, SUM(a.result) > FROM [ \{"handle": "one", "result": 23}, > \{"handle": "two", "result": 64}, > \{"handle": "two", "result": 6}, > \{"handle": "four", "result": 34}, > \{"handle": "two", "result": 3} ] AS a; > The error message is: > ASX1073: Cannot resolve alias reference for undefined identifier a (in line > 1, at column 8) > Note that the following query works fine, which leads to serious > head-scratching by the user: > SELECT a.handle, to_string(a.result) > FROM [ \{"handle": "one", "result": 23}, > \{"handle": "two", "result": 64}, > \{"handle": "two", "result": 6}, > \{"handle": "four", "result": 34}, > \{"handle": "two", "result": 3} ] AS a; > The real problem is the inappropriate use of an aggregate function (SUM) - > but the alias error gives no clue! Here is how MySQL complains about this: > Error Code: 1140. In aggregated query without GROUP BY, expression #1 of > SELECT list contains nonaggregated column 'a.handle'; > Can we do something similar? I think the problem is that we rewrite the > query internally and then something about the rewritten internal query leads > to the error we currently produce. -- This message was sent by Atlassian JIRA (v7.6.3#76005)