drill-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jacques Nadeau (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DRILL-3477) Using IntVector for null expressions causes problems with implicit cast
Date Thu, 09 Jul 2015 02:24:04 GMT

    [ https://issues.apache.org/jira/browse/DRILL-3477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14619753#comment-14619753

Jacques Nadeau commented on DRILL-3477:

I really think that we should simply add a null vector.  It seems like this is just a different
hack that will cause different problems.

> Using IntVector for null expressions causes problems with implicit cast
> -----------------------------------------------------------------------
>                 Key: DRILL-3477
>                 URL: https://issues.apache.org/jira/browse/DRILL-3477
>             Project: Apache Drill
>          Issue Type: Bug
>            Reporter: Steven Phillips
>            Assignee: Jinfeng Ni
> See DRILL-3353, for example.
> A simple example is this:
> {code}
> select * from t where a = 's';
> {code}
> If the first batch scanned from table t does not contain the column a, the expression
materializer in Project defaults to Nullable Int as the type. The Filter then sees an Equals
expression between a VarChar and an Int type, so it does an implicit cast. Implicit cast rules
give Int higher precedence, so the literal 's' is cast to Int, which ends up throwing a NumberFormatException.
> In the class ResolverTypePrecedence, we see that Null type has the lowest precedence,
which makes sense. But since we don't actually currently have an implementation for NullVector,
we should materialize the Null type as the Vector with the lowest possible precedence, which
is VarBinary.
> My suggestion is that we should use VarBinary as the default type in ExpressionMaterializer
instead of Int.

This message was sent by Atlassian JIRA

View raw message