This makes sense, and furthermore, it might be easier to do it in Optiq’s 
parser. Optiq’s parser handles non-reserved keywords as follows: first it 
converts the token (say “ABSOLUTE”) into a token, but the Identifier() rule 
calls NonReservedKeyWord() to convert the token back into an identifier if it 
is used in a location where an identifier would be appropriate. Maybe this 
could be extended to reserved keywords also.

See also SqlParserTest.testExceptionCleanup, which does something very similar 
to what Jason is suggesting.

Julian


On Jul 30, 2014, at 2:46 PM, Jason Altekruse <[email protected]> wrote:

> While this is a common problem for parsers to crap out on misuse of
> reserved words, it might make sense to produce a warning when the error
> from the parser likely has something to do with an un-escaped reserved
> word. Would it be crazy to take the error message from optiq and search it
> for terms from the reserved words list? I know this is a rather weak model
> for talking to a dependency, but it may help to improve usability some and
> prevent JIRA's from being opened, as we have already seen several issues
> opened for rare reserved words causing confusion.
> 
> -Jason
> 
> 
> On Wed, Jul 30, 2014 at 4:25 PM, Bob Rumsby <[email protected]> wrote:
> 
>> Oops, thanks. Bangs head on laptop...
>> 
>> 
>> On Wed, Jul 30, 2014 at 12:31 PM, Ramana Inukonda <[email protected]>
>> wrote:
>> 
>>> year is a reserved keyword.
>>> 
>>> select columns[1] as `year` from
>>> dfs.`/drill/testdata/text_storage/lineitem.tbl` limit 10;
>>> 
>>> works.
>>> 
>>> Regards
>>> 
>>> Ramana
>>> 
>>> 
>>> 
>>> 
>>> On Wed, Jul 30, 2014 at 12:23 PM, Bob Rumsby <[email protected]>
>> wrote:
>>> 
>>>> Should I file a bug for this?
>>>> 
>>>> 0: jdbc:drill:zk=local> select columns[0] as year, columns[1] as play
>>> from
>>>> dfs.`/Users/brumsby/drill/plays.csv`;
>>>> Query failed: org.apache.drill.exec.rpc.RpcException: Remote failure
>>> while
>>>> running query.[error_id: "4929bef3-1dde-4e51-a9f2-a3722687f139"
>>>> endpoint {
>>>>  address: "10.250.0.28"
>>>>  user_port: 31010
>>>>  control_port: 31011
>>>>  data_port: 31012
>>>> }
>>>> error_type: 0
>>>> message: "Failure while parsing sql. < SqlParseException:[ Encountered
>>> "as
>>>> year" at line 1, column 19.
>>>> Was expecting one of:
>>>>    "FROM" ...
>>>>    "," ...
>>>>    "AS" <IDENTIFIER> ...
>>>>    "AS" <QUOTED_IDENTIFIER> ...
>>>>    "AS" <BACK_QUOTED_IDENTIFIER> ...
>>>> ...
>>>> 
>>> 
>> 

Reply via email to