mirror of
https://github.com/apache/impala.git
synced 2025-12-30 12:02:10 -05:00
635dd7d289
Partition column expressions are analysed twice for INSERT statements - once to infer the type and so to add a possible cast, and once to compute stats on the resulting expr. However, this process resulted in an partition column expr that was a IntLiteral getting the smallest type that would contains its value, rather than retaining the column-compatible type that had been assigned to it. This patch does the minimum thing, which is make IntLiteral.analyze() idempotent. Doing the same thing to Expr and LiteralExpr unearths some other bugs, which we will have to fix in a follow-on patch (see IMPALA-884). Change-Id: Ie22fc5d3f4832c735a1ebc0ef78f50d736f597fd Reviewed-on: http://gerrit.ent.cloudera.com:8080/1931 Reviewed-by: Henry Robinson <henry@cloudera.com> Tested-by: jenkins (cherry picked from commit 1912d65ea21a5025d385948642f0d4aadad91abf) Reviewed-on: http://gerrit.ent.cloudera.com:8080/1947
20 lines
900 B
Plaintext
20 lines
900 B
Plaintext
====
|
|
# Pre IMPALA-875, IntLiterals with value 1 would be cast to TINYINT during analysis of
|
|
# the insert statement.
|
|
#
|
|
# In this example, we create a partitioned table with three partitions whose partition
|
|
# columns are equal when evaluated TINYINT (i.e. mod 1024). The backend will fail if
|
|
# more than one partition is considered a potential target for an INSERT when
|
|
# considering its statically specified partition keys.
|
|
---- QUERY
|
|
DROP TABLE IF EXISTS functional.insert_partition_key_type_promotion;
|
|
CREATE TABLE functional.insert_partition_key_type_promotion (c int)
|
|
PARTITIONED BY (p int);
|
|
ALTER TABLE functional.insert_partition_key_type_promotion ADD PARTITION(p=1025);
|
|
ALTER TABLE functional.insert_partition_key_type_promotion ADD PARTITION(p=2049);
|
|
# Will fail pre IMPALA-875
|
|
INSERT INTO functional.insert_partition_key_type_promotion PARTITION(p=1) VALUES(1)
|
|
---- RESULTS
|
|
p=1/: 1
|
|
====
|