Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SQL INSERT casts to Int64 when handling UInt64 values #14208

Open
nuno-faria opened this issue Jan 20, 2025 · 1 comment · May be fixed by #14223
Open

SQL INSERT casts to Int64 when handling UInt64 values #14208

nuno-faria opened this issue Jan 20, 2025 · 1 comment · May be fixed by #14223
Labels
bug Something isn't working

Comments

@nuno-faria
Copy link
Contributor

Describe the bug

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]
async fn main() -> 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.

@nuno-faria nuno-faria added the bug Something isn't working label Jan 20, 2025
@jonahgao
Copy link
Member

jonahgao commented Jan 21, 2025

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
2 participants