As far as I can tell, the SQL grammar is based on the ASCII subset of Unicode,
meaning that SQL allows only the "full stop" (.) character, but not the Unicode
variations.
Since the SQL standard defines the meaning of the full stop, Drill probably
does not want to allow variations.
It seems various vendors have come up with different markers for Unicode
characters in constants or names. (I believe Drill uses UTF-8 as its native
character set, so none of these hacks are necessary.)
Perhaps either Python does allow variations, or the editor was doing the
translation?
Although the various Drill tools could try to play this trick, the problem
would be knowing when to do the substitution (outside of constants and names)
and when to leave the characters alone (when quoted.)
I wonder, how do uses of such keyboards handle the case of editing, say, C code
which has an old-school grammar based on ASCII for its tokens? Must be some
standard technique.
Thanks,
- Paul
On Tuesday, August 7, 2018, 7:22:37 AM PDT, Charles Givre
<cgi...@gmail.com> wrote:
That was the interesting part. The python code that was using that character
wasn’t seeming to fail. It was the quoted query that was being sent to Drill
that was failing.
Sent from my iPhone
> On Aug 7, 2018, at 07:20, Pradeeban Kathiravelu <kk.pradee...@gmail.com>
> wrote:
>
> If I understand correctly, he was using the character ・
>
> Different languages have different symbols.
>
> The same thing can be said about the Chinese equivalent 。
>
> The characters ・and 。 are entirely different from the "."
> Not sure whether this needs to be fixed. If I am not completely
> misunderstanding something, he will also fail if he attempts to use that
> character (in place of ".") in programming languages (Java, C, ..).
>
> Regards,
> Pradeeban.
>
>> On Tue, Aug 7, 2018 at 10:02 AM, Charles Givre <cgi...@gmail.com> wrote:
>>
>> Hello Drill Developers,
>> I wanted to share an interesting development that happened yesterday. I
>> was teaching a class at BlackHat, and we have a worksheet that includes a
>> Drill demonstration using PyDrill. Basically the students are asked to
>> execute a query in Drill using PyDrill then visualize the results.
>>
>> Anyway, a student from Japan tried this, and was getting all kinds of
>> crazy errors. So I sat down and worked with him to debug. It turns out
>> that the period on the Japanese keyboard, maps to a different unicode
>> character than on US keyboards, and hence the queries throw errors. I
>> discovered this because when I would cut/paste a query from a text file
>> that I wrote, the query executed, but if we typed one in, it broke. After
>> digging around a bit, I found that it was the period character.
>>
>> I’m not sure that this can or should be fixed, but I wanted to let people
>> know about this.
>>
>> Best,
>> — C
>
>
>
>
> --
> Pradeeban Kathiravelu.
> Senior Systems Software Engineer, Emory University, Atlanta, GA, USA.
> Ph.D. Researcher, Erasmus Mundus Joint Doctorate in Distributed Computing,
> INESC-ID Lisboa / Instituto Superior Técnico, Universidade de Lisboa,
> Portugal.
> Université catholique de Louvain, Louvain-la-Neuve, Belgium.
>
> Blog: [Llovizna] kkpradeeban.blogspot.com
> LinkedIn: www.linkedin.com/in/kpradeeban
