[
https://issues.apache.org/jira/browse/HIVE-11723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14901728#comment-14901728
]
Yongzhi Chen commented on HIVE-11723:
-------------------------------------
[~szehon], I think the changes only affect values clause: something like
values('...')
This fix makes string literal in values clause more consistent with string
literals in other part of the SQL such as:
select 'a\'b' from src
The string literal above is processed in TypeCheckProcFactory as following
{noformat}
public static class StrExprProcessor implements NodeProcessor {
@Override
public Object process(Node nd, Stack<Node> stack, NodeProcessorCtx procCtx,
Object... nodeOutputs) throws SemanticException {
TypeCheckCtx ctx = (TypeCheckCtx) procCtx;
if (ctx.getError() != null) {
return null;
}
ExprNodeDesc desc = TypeCheckProcFactory.processGByExpr(nd, procCtx);
if (desc != null) {
return desc;
}
ASTNode expr = (ASTNode) nd;
String str = null;
switch (expr.getToken().getType()) {
case HiveParser.StringLiteral:
str = BaseSemanticAnalyzer.unescapeSQLString(expr.getText());
break;
....
{noformat}
So the change in the patch should not have backward compatible issues.
> Incorrect string literal escaping
> ---------------------------------
>
> Key: HIVE-11723
> URL: https://issues.apache.org/jira/browse/HIVE-11723
> Project: Hive
> Issue Type: Bug
> Affects Versions: 1.2.0, 1.1.1, 2.0.0
> Reporter: Uri Laserson
> Assignee: Yongzhi Chen
> Attachments: HIVE-11723.1.patch
>
>
> When I execute the following queries
> {code}
> CREATE TABLE t_hive (f1 STRING);
> INSERT INTO t_hive VALUES ('Cooper\'s');
> SELECT * FROM t_hive;
> {code}
> via the Hive shell or through HiveServer2 directly (via impyla), I would
> expect that the result to be
> {code}
> Cooper's
> {code}
> but instead I actually get
> {code}
> Cooper\'s
> {code}
> Actually, I'm not sure how that {{INSERT}} query is not even a syntax error.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
