risingwavelabs/risingwave · error

unknown minimal compatible type for {a:?} and {b:?}

Error message

unknown minimal compatible type for {a:?} and {b:?}

What it means

This panic comes from `min_compatible_type` in RisingWave's type macro crate, which computes the minimal (least restrictive) common type that two scalar types can be coerced into. The function enumerates an exhaustive table of known compatible type pairs (e.g. date/timestamp -> timestamp, time/interval -> interval). When it receives a pair it has no mapping for, it panics with the debug-formatted pair, signaling an unhandled type combination rather than a user-facing error.

Source

Thrown at src/expr/macro/src/types.rs:150

        ("int256", "int4") => "int256",
        ("int256", "int8") => "int256",
        ("int256", "float8") => "float8",
        ("float8", "int256") => "float8",

        ("float4", "float4") => "float4",
        ("float4", "float8") => "float8",

        ("float8", "float4") => "float8",
        ("float8", "float8") => "float8",

        ("decimal", "decimal") => "decimal",

        ("date", "timestamp") => "timestamp",
        ("timestamp", "date") => "timestamp",
        ("time", "interval") => "interval",
        ("interval", "time") => "interval",

        (a, b) => panic!("unknown minimal compatible type for {a:?} and {b:?}"),
    }
}

View on GitHub (pinned to 6469eb736d)

Solutions

1. Add a mapping arm for the offending (a, b) pair in the match in src/expr/macro/src/types.rs returning the intended minimal type.
2. Explicitly cast one of the operands to a shared type upstream so the pair hits an existing arm.
3. If the pair is genuinely incompatible, reject it earlier with a proper error instead of reaching type unification.

Example fix

// before
(a, b) => panic!("unknown minimal compatible type for {a:?} and {b:?}"),
// after
("varchar", "varchar") => "varchar",
(a, b) => panic!("unknown minimal compatible type for {a:?} and {b:?}"),

// check pair is supported before calling
fn is_supported(a: &DataType, b: &DataType) -> bool {
    matches!((a, b), (DataType::Date, DataType::Timestamp) | (DataType::Time, DataType::Interval) | ..)
}

fn has_min_compatible(a: &DataType, b: &DataType) -> bool { MIN_COMPAT_TABLE.contains(&(a, b)) }

// panics instead of returning Result: pre-validate the pair, or wrap in catch_unwind for test harnesses
let compat = std::panic::catch_unwind(|| min_compatible_type(a, b));

When it happens

Trigger: Calling `min_compatible_type(a, b)` with a type pair absent from the match table, e.g. two unrelated primitive types like `varchar` and `timestamp` or custom/newly added types not yet registered in the compatibility table.

Common situations: Adding a new data type to RisingWave and forgetting to extend the compatibility table; planner/expr code paths performing implicit type unification on columns of mismatched types; tests feeding unusual type combinations.

Understand the failure class

Background: "This is a bug, please report it": internal invariant violations, unreachable panics, and SNH errors explained — this error's family across 47 libraries.

Related errors

• failed to parse static creds
• unexpected statement type: {:?}
• no chunk in IngestDmlPayloadRequest
• failed to convert JSON schema to Avro schema: {}
• not yet implemented

AI-assisted analysis of risingwavelabs/risingwave@6469eb736d (2026-09-11). Data as JSON: /api/errors/d00ec301476ed91a. Report an issue: GitHub.