Thanks Vlad a couple of thoughts.
A. I think that should be fixed. That seems like a limitation that is both unexpected and undocumented. B. Is there a way, if my data in the table is returned as binary to start with, for me to return the first 256 bytes? I tried substring, and tries to force to UTF-8 and I am getting some issues there. On Tue, Jul 17, 2018 at 10:33 AM, Vlad Rozov <[email protected]> wrote: > In case of DRILL-6607 the issue lies in the implementation of > "string_binary" function: it is not prepared to handle incoming data that > when converted to a binary string would exceed 256 bytes as it does not > reallocate the output buffer. Until the function code is fixed, the only > way to avoid the error is either not to use "string_binary" or to use it > with the data that meets "string_binary" limitation. > > Thank you, > > Vlad > > > On 7/13/18 14:01, Ted Dunning wrote: > >> There are bounds for acceptable behavior for a function like this. Array >> index out of bounds is not acceptable. Aborting with a clean message about >> to true problem might be fine, as would be to return a null. >> >> On Fri, Jul 13, 2018, 13:46 John Omernik <[email protected]> wrote: >> >> So, as to the actual problem, I opened a JIRA here: >>> >>> https://issues.apache.org/jira/browse/DRILL-6607 >>> >>> The reason I brought this here is my own curiosity: Does an issue in >>> using >>> this function most likely lie in the function code itself not handling >>> good >>> data, or is the issue in the pcap pluglin which produces the data for >>> this >>> function to consume, I am just curious on how something like this could >>> be >>> avoided. >>> >>> John >>> >>> >
