[
https://issues.apache.org/jira/browse/DRILL-2880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14513277#comment-14513277
]
Julian Hyde commented on DRILL-2880:
------------------------------------
Might be a sign that the parser is trying to do too much validation. IMHO the
parser should return a complete AST before [semantic] validation starts. That
means the AST needs to be able to refer to a file that does not exist, and
indeed to numbers which are too large to be held in BIGINTs.
> non-syntax error has unexpected category "PARSE ERROR"
> ------------------------------------------------------
>
> Key: DRILL-2880
> URL: https://issues.apache.org/jira/browse/DRILL-2880
> Project: Apache Drill
> Issue Type: Bug
> Components: SQL Parser
> Reporter: Daniel Barclay (Drill)
> Assignee: Aman Sinha
> Priority: Minor
>
> Some errors that are not syntax errors (failures to match the productions of
> the SQL grammar), such as referring to a non-existent table:
> SELECT * FROM NoSuchFile;
> yield error messages that unexpectedly refer to parsing, such as:
> PARSE ERROR: From line 1, column 15 to line 1, column 26: Table 'NoSuchFile'
> not found
>
> That "PARSE ERROR" sounds like it's saying it's specifically a parsing error,
> when it's really an error downstream of parsing.
> (A parsing error requires changing the query to conform to the grammar. In
> the above case, creating a file or view would resolve the problem without
> changing the query, so the problem is not a parsing error.)
>
> Its not clear whether that error should be reported using a different
> existing or new error category, or whether the category "PARSE ERROR" should
> be renamed (to cover both real parsing errors and the level of errors).
> Note, however, that to avoid confusion, errors that can be fixed by changing
> something other than the query (i.e., the data store state) probably should
> not be reported using the same category as true syntax/parsing errors.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
