SeaQL/sea-orm · error

Failed to get big integer

Error message

Failed to get big integer

What it means

Panic while converting a Postgres row to ProxyRow: a column matched as BIGINT/BIGSERIAL/INT8 is decoded with `row.try_get::<i64>(ordinal).expect("Failed to get big integer")`. `try_get` fails when the value is NULL (scalar i64 target rejects NULL, `UnexpectedNullError`) or the value cannot decode as i64 despite the reported type name (e.g. a DOMAIN over bigint or a shadowed type).

Source

Thrown at sea-orm-sync/src/driver/sqlx_postgres.rs:493

                        ),

                        "INT" | "SERIAL" | "INT4" => {
                            Value::Int(row.try_get(c.ordinal()).expect("Failed to get integer"))
                        }
                        #[cfg(feature = "postgres-array")]
                        "INT[]" | "SERIAL[]" | "INT4[]" => Value::Array(
                            sea_query::ArrayType::Int,
                            row.try_get::<Option<Vec<i32>>, _>(c.ordinal())
                                .expect("Failed to get integer array")
                                .map(|vals: Vec<i32>| {
                                    Box::new(
                                        vals.into_iter().map(|val| Value::Int(Some(val))).collect(),
                                    )
                                }),
                        ),

                        "BIGINT" | "BIGSERIAL" | "INT8" => Value::BigInt(
                            row.try_get(c.ordinal()).expect("Failed to get big integer"),
                        ),
                        #[cfg(feature = "postgres-array")]
                        "BIGINT[]" | "BIGSERIAL[]" | "INT8[]" => Value::Array(
                            sea_query::ArrayType::BigInt,
                            row.try_get::<Option<Vec<i64>>, _>(c.ordinal())
                                .expect("Failed to get big integer array")
                                .map(|vals: Vec<i64>| {
                                    Box::new(
                                        vals.into_iter()
                                            .map(|val| Value::BigInt(Some(val)))
                                            .collect(),
                                    )
                                }),
                        ),

                        "FLOAT4" | "REAL" => {
                            Value::Float(row.try_get(c.ordinal()).expect("Failed to get float"))
                        }

View on GitHub (pinned to e29bcd1b41)

Solutions

  1. Decode as Option: `row.try_get::<Option<i64>, _>(c.ordinal())` and map to `Value::BigInt(opt)`.
  2. COALESCE in SQL (`COALESCE(SUM(x), 0)`) when NULL aggregates should default to 0.
  3. ALTER TABLE ... SET NOT NULL (with DEFAULT) on columns guaranteed non-null.
  4. Cast away DOMAINs (`col::bigint`) so the decode target matches i64.
  5. Check `pg_typeof(col)`/search_path for shadowed types and correct schema or the type-name match.

Example fix

// before (panics on NULL)
"BIGINT" | "BIGSERIAL" | "INT8" => Value::BigInt(
    row.try_get(c.ordinal()).expect("Failed to get big integer"),
),
// after (NULL-safe)
"BIGINT" | "BIGSERIAL" | "INT8" => Value::BigInt(
    row.try_get::<Option<i64>, _>(c.ordinal())
        .expect("Failed to get big integer")
        .unwrap_or_default(),
),
Defensive patterns

Strategy: try-catch

Validate before calling

// SELECT column_name, is_nullable, data_type FROM information_schema.columns
//   WHERE table_name = 't' AND data_type = 'bigint';
// NULL from aggregates: SELECT COALESCE(SUM(x), 0)::bigint FROM t;

Type guard

fn as_i64(row: &ProxyRow, col: &str) -> Option<i64> {
    match row.value(col) {
        Some(Value::BigInt(v)) => v,
        _ => None,
    }
}

Try / catch

let result = std::panic::catch_unwind(|| proxy_row_get_i64(&row, "total"));
match result {
    Ok(v) => v,
    Err(_) => treat_as_null_or_default(), // SUM/MAX over empty sets return NULL
}

Prevention

When it happens

Trigger: Reading a nullable int8 column through ProxyRow (outer-join misses, nullable views); querying a Postgres DOMAIN over bigint; bigserial id columns appearing as NULL in a LEFT JOIN result.

Common situations: Nullable FK columns of type bigint read via raw/ProxyRow queries; views projecting nullable values over NOT NULL base columns; DOMAIN types over bigint; count()/aggregate columns cast to bigint that come back NULL in empty-set aggregations (`COUNT` returns 0, but `SUM`/`MAX` return NULL).

Understand the failure class

Background: Type mismatch errors: IllegalArgumentException, TypeError and type guards across 150 open-source libraries — this error's family across 150 libraries.

Related errors


AI-assisted analysis of SeaQL/sea-orm@e29bcd1b41 (2026-09-10). Data as JSON: /api/errors/1cf868fa3ccc917e. Report an issue: GitHub.