You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When performing a SQL INSERT to a BIGINT UNSIGNED column, the wrong type is assumed when mixing UInt64 data with values that can be represented in Int64. However, it works when the inserted values must all be represented in UInt64.
To Reproduce
use datafusion::common::Result;use datafusion::prelude::SessionContext;#[tokio::main]asyncfnmain() -> Result<()>{let ctx = SessionContext::new();// column is declared as bigint unsigned
ctx.sql("create table t (v bigint unsigned)").await?;let value:u64 = 10000000000000000000;// works: all values are u64
ctx.sql(format!("insert into t values ({value}), ({value})").as_str()).await?.collect().await?;
ctx.sql("select * from t").await?.show().await?;// does not work: one of the values forces the type to be Int64, invalidating {value}// Error: ArrowError(CastError("Can't cast value 10000000000000000000 to type Int64"), None)
ctx.sql(format!("insert into t values ({value}), (1)").as_str()).await?.collect().await?;
ctx.sql("select * from t").await?.show().await?;Ok(())}
Expected behavior
When at least one of the values must be encoded with UInt64, the assumed type must be UInt64.
Additional context
I can take a look at this issue, but wanted to first make sure this is a bug and not expected behavior.
The text was updated successfully, but these errors were encountered:
This seems to be a bug in binary_numeric_coercion. The common type of UInt64 and Int8/16/32/64 should not be Int64, because u64::MAX can't fit into it. It should be a wider type, for example, Decimal128(20, 0).
Describe the bug
When performing a SQL
INSERT
to aBIGINT UNSIGNED
column, the wrong type is assumed when mixingUInt64
data with values that can be represented inInt64
. However, it works when the inserted values must all be represented inUInt64
.To Reproduce
Expected behavior
When at least one of the values must be encoded with
UInt64
, the assumed type must beUInt64
.Additional context
I can take a look at this issue, but wanted to first make sure this is a bug and not expected behavior.
The text was updated successfully, but these errors were encountered: