[
https://issues.apache.org/jira/browse/HIVE-24777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Panagiotis Garefalakis updated HIVE-24777:
------------------------------------------
Description:
Currently, Hive does some type safety checks looking for lossy type conversions
such as: decimal to char, and long to varchar (even though not complete).
These conversion are not documented and they might even differ depending on the
CBO status. For example:
{code:java}
set hive.cbo.enable=false;
create table comparison_table (col_v varchar(3), col_i int) stored as orc;
insert into comparison_table values ('001', 15), ('002', 25), ('007', 75);
select * from comparison_table where col_v >= 4L;
// Converts to pred '4' to String
// No result when CBO off
set hive.cbo.enable=on;
select * from comparison_table where col_v >= 4L;
// Converts both to Double
// 007 when CBO is on
{code}
Type conversions on the predicates also affect Sargs evaluation as in the first
case (cbo off) string padding is missing, and in the latter case (cbo on)
UDFBridge can no be evaluated.
Finally, it seems that there are multiple configuration tracking the same thing:
* hive.strict.timestamp.conversion
* hive.strict.checks.type.safety
This uber Jira is targeting the standardisation/documentation of these type
checks and their conversions on Hive.
was:
Currently, Hive does some type safety checks looking for loosy type conversions
such as: decimal to char, and long to varchar (even though not complete).
These conversion are not documented and they might even differ depending on the
CBO status. For example:
{code:java}
set hive.cbo.enable=false;
create table comparison_table (col_v varchar(3), col_i int) stored as orc;
insert into comparison_table values ('001', 15), ('002', 25), ('007', 75);
select * from comparison_table where col_v >= 4L;
// Converts to pred '4' to String
// No result when CBO off
set hive.cbo.enable=on;
select * from comparison_table where col_v >= 4L;
// Converts both to Double
// 007 when CBO is on
{code}
Type conversions on the predicates also affect Sargs evaluation as in the first
case (cbo off) string padding is missing, and in the latter case (cbo on)
UDFBridge can no be evaluated.
Finally, it seems that there are multiple configuration tracking the same thing:
* hive.strict.timestamp.conversion
* hive.strict.checks.type.safety
This uber Jira is targeting the standardisation/documentation of these type
checks and their conversions on Hive.
> Standardize Hive's Type conversions
> -----------------------------------
>
> Key: HIVE-24777
> URL: https://issues.apache.org/jira/browse/HIVE-24777
> Project: Hive
> Issue Type: Improvement
> Reporter: Panagiotis Garefalakis
> Priority: Major
>
> Currently, Hive does some type safety checks looking for lossy type
> conversions such as: decimal to char, and long to varchar (even though not
> complete).
> These conversion are not documented and they might even differ depending on
> the CBO status. For example:
> {code:java}
> set hive.cbo.enable=false;
> create table comparison_table (col_v varchar(3), col_i int) stored as orc;
> insert into comparison_table values ('001', 15), ('002', 25), ('007', 75);
> select * from comparison_table where col_v >= 4L;
> // Converts to pred '4' to String
> // No result when CBO off
> set hive.cbo.enable=on;
> select * from comparison_table where col_v >= 4L;
> // Converts both to Double
> // 007 when CBO is on
> {code}
> Type conversions on the predicates also affect Sargs evaluation as in the
> first case (cbo off) string padding is missing, and in the latter case (cbo
> on) UDFBridge can no be evaluated.
> Finally, it seems that there are multiple configuration tracking the same
> thing:
> * hive.strict.timestamp.conversion
> * hive.strict.checks.type.safety
> This uber Jira is targeting the standardisation/documentation of these type
> checks and their conversions on Hive.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
