[ 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)