[jira] [Commented] (IMPALA-1652) Fix CHAR datatype: Incorrect results with basic predicate on CHAR typed column.

["ASF subversion and git services (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/IMPALA-1652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17764282#comment-17764282 ] 

ASF subversion and git services commented on IMPALA-1652:
---------------------------------------------------------

Commit 9f05cf79fa385ee6a5245ec7cb9ec1b9302c543d in impala's branch refs/heads/master from Michael Smith
[ https://gitbox.apache.org/repos/asf?p=impala.git;h=9f05cf79f ]

IMPALA-10086: Implicit cast comparing char and varchar

Until IMPALA-7368, Impala allowed comparing char and varchar slots as in

  select * from functional.chars_tiny where cs = vc;

IMPALA-7368 added DATE type support, and as part of that changed
function call resolution to use a fit function based on the number of
arguments that match the call types. Previously the comparison above
would take the first matching function, which happened to be equality
between STRING and STRING; CHAR and VARCHAR can both be implicitly cast
to STRING, so this function worked. With the new function resolution,
the best fit is equality between VARCHAR and VARCHAR, however implicit
casting to VARCHAR(*) from CHAR wasn't allowed.

The behavior before IMPALA-7368 was somewhat accidental; it depended on
the order that builtin EQ functions are added via
BinaryPredicate.initBuiltins -> Type.getSupportedTypes. Supported types
happened to be ordered with STRING preceding VARCHAR and CHAR. The fit
function makes sense and changing its behavior may have other
consequences; it also makes sense that CHAR should be castable to
VARCHAR.

This change allows implicit cast between matching types. Functionally it
only changes how we handle char/varchar comparison with wildcard
char/varchar, because decimals are handled before checking for matching
types and other type matching is the same as equals. It now allows
casting to a compatible type when it is a char or varchar and the target
type is a wildcard version of the same.

Does not attempt to address differences from CHAR padding (IMPALA-1652).

Testing:
- Adds tests covering cast comparison and other implicit conversions.
- Passed exhaustive test run.

Change-Id: Ib89d0a391bc8f2152ecd9151c8872a01ba19c436
Reviewed-on: http://gerrit.cloudera.org:8080/20425
Reviewed-by: Peter Rozsa <pr...@cloudera.com>
Reviewed-by: Daniel Becker <da...@cloudera.com>
Tested-by: Impala Public Jenkins <im...@cloudera.com>


> Fix CHAR datatype: Incorrect results with basic predicate on CHAR typed column.
> -------------------------------------------------------------------------------
>
>                 Key: IMPALA-1652
>                 URL: https://issues.apache.org/jira/browse/IMPALA-1652
>             Project: IMPALA
>          Issue Type: Bug
>          Components: Backend
>    Affects Versions: Impala 2.1, Impala 2.3.0
>            Reporter: Alexander Behm
>            Priority: Major
>              Labels: correctness, downgraded, usability
>         Attachments: 8be18d4.diff
>
>
> Repro:
> {code}
> create table foo(col1 char(10));
> insert into foo values (cast('test1' as char(10)));
> select * from foo where col1 = 'test1'; <-- returns an empty result set
> select * from foo where col1 = cast('test1' as char(10)); <-- correctly returns 1 row
> {code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-all-unsubscribe@impala.apache.org
For additional commands, e-mail: issues-all-help@impala.apache.org