[
https://issues.apache.org/jira/browse/IMPALA-5723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jim Apple resolved IMPALA-5723.
-------------------------------
Resolution: Information Provided
Fix Version/s: Product Backlog
Unfortunately, Apache Impala does not ship with a JDBC driver. There is a Hive
driver and a driver distributed by Cloudera, but neither of those products use
the Apache Impala JIRA for bug reporting.
> 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
> Labels: JDBC
> Fix For: Product Backlog
>
> 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)
