impala-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Apple <jbap...@cloudera.com>
Subject Re: IMPALA-2428 Support multiple-character string as the field delimiter
Date Tue, 26 Jul 2016 20:15:20 GMT
I may be alone in this, but I am finding the long posts, with logs of shell
sessions intermixed with paragraphs of regular text, very difficult to read
and understand.

On Sun, Jul 24, 2016 at 7:53 PM, Yuanhao Luo <luoyuanhao@software.ict.ac.cn>
wrote:

> Hello, Jim Apple, I have test original delimiters  setting, and logs
> show's the difference of my commit and original setting, as below:
>
> *My commit*
>                *Original setting*
>
>    1. Field terminators can't be an empty string.
>    All terminators can't be empty. (I will enhance restriction to this in my
>    next patch)
>    2. Tuple delimiter can't be the first byte of field delimiter
>    Field delimiter and line delimiter can't be the same value(So these two
>    restrictions are actually the same one)
>
> Why are these the same one?

>
>    1. Escaped char can't be the first byte of field delimiter
>     Warning: Escaped char will be ignored(I will relax my restriction to this
>    in my next patch)
>    2. No restriction for escaped char and line terminator
>    Warning: Escaped char will be ignored(I will add this warning in my next
>    patch)
>    3. Terminator contains '\0'
>              ImpalaRuntimeException(logs for detail. I add this restriction to
>    fix this runtime exception.)
>
>
I don't understand this last one. The rest are phrased as statements like
"X can't be Y". This last one is "X contains Y". Are you saying "X must not
contain Y"

Also, I don't understand what "I add this restriction to fix this runtime
exception." means. Are you saying that, in your patch, when the terminator
contains '\0', you fail in a more orderly way than the current code does?

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message