Mailing-List: contact dev-help@drill.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@drill.apache.org
Date: Thu, 9 Jul 2015 02:10:04 +0000 (UTC)
From: "Steven Phillips (JIRA)" <jira@apache.org>
To: dev@drill.apache.org
Message-ID: <JIRA.12843727.1436407746000.137660.1436407804660@Atlassian.JIRA>
In-Reply-To: <JIRA.12843727.1436407746000@Atlassian.JIRA>
References: <JIRA.12843727.1436407746000@Atlassian.JIRA>
 <JIRA.12843727.1436407746791@arcas>
Subject: [jira] [Created] (DRILL-3477) Using IntVector for null expressions
 causes problems with implicit cast
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Steven Phillips created DRILL-3477:
--------------------------------------

             Summary: 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: Steven Phillips


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
(v6.3.4#6332)