New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[SPARK-14426][SQL] Merge PerserUtils and ParseUtils #12199
Conversation
Test build #55090 has finished for PR 12199 at commit
|
LGTM |
Yay! LGTM. |
// scalastyle:on nonascii | ||
} | ||
|
||
// TODO: Add test cases for other methods in ParserUtils |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah you have a point there. These methods are all tested indirectly in the *ParserSuite
's.
Test build #55095 has finished for PR 12199 at commit
|
Test build #2758 has finished for PR 12199 at commit
|
int base = i + 2; | ||
for (int j = 0; j < 4; j++) { | ||
int digit = Character.digit(b.charAt(j + base), 16); | ||
code += digit * multiplier[j]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@sarutak If understand this correctly they are shifting a hexidecimal value using a decimal multiplier. This would kinda work as long as you pass in decimal unicode literals :s...
Do you think that we should file a bug with the Hive project?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I'm thinking about reporting this issue.
Test build #55106 has finished for PR 12199 at commit
|
Merging into master thanks. |
What changes were proposed in this pull request?
We have ParserUtils and ParseUtils which are both utility collections for use during the parsing process.
Those names and what they are used for is very similar so I think we can merge them.
Also, the original unescapeSQLString method may have a fault. When "\u0061" style character literals are passed to the method, it's not unescaped successfully.
This patch fix the bug.
How was this patch tested?
Added a new test case.