[jira] [Created] (IMPALA-5723) JDBC Driver's parser robustness issues

["Julian Eberius (JIRA)" <ji...@apache.org>]

Julian Eberius created IMPALA-5723:
--------------------------------------

             Summary: JDBC Driver's parser robustness issues
                 Key: IMPALA-5723
                 URL: https://issues.apache.org/jira/browse/IMPALA-5723
             Project: IMPALA
          Issue Type: Bug
          Components: Clients
    Affects Versions: Impala 2.8.0
         Environment: CDH 5.10 cluster, Impala JDBC driver version 2.5.38
            Reporter: Julian Eberius
            Priority: Minor
         Attachments: ParserRobustnessTest.java

We have encountered robustness issues with the Impala JDBC driver's parser related to various special characters included in string literals.

They appear as soon as escaped quotes are used in string literals, e.g 
{code:sql}
select * from test where field in ('te\'st', 'test #1');
{code}
will lead to an exception "unmatched string literal". See the attached unit tests. 

Some issues can worked around, e.g., the above works when the JDBC Statement method setEscapeProcessing(false) is called. However, other cases cannot be fixed this way, e.g. 
{code:sql}
select * from test where field in ('te\'st', 'test #1', 'test ??');
{code}
This leads to "Parameters cannot be used with normal Statement objects, use PreparedStatements instead". Again, see the attached unit test. 

Finally, we noticed, that be bug can be worked around by adding additional quotes in comments (!!), which seems to reset the parser.
{code:sql}
select * from test where field in ('te\'st' /*'*/, 'test #1', 'test ??');
{code}
Sometimes, the issue can also be worked around by moving the strings with the quote to the back of the list. 

From looking at the decompiled source code, it seems that at least the com.cloudera.hivecommon.core.CoreUtils and the com.cloudera.jdbc.utils.ParseQueryUtils classes seem to be connected to these bugs.

The expected outcome is that quotes in string literals can be escaped without triggering bugs, and that other characters inside literals have no effect on the parser.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)