clockworklabs/SpacetimeDB · error · anyhow::Error

Literal values for type {} are not supported

Error message

Literal values for type {} are not supported

What it means

When the SQL frontend converts a literal from query text into a typed AlgebraicValue, only scalar types are supported: all integer widths (I8..U256), floats, String, timestamp, bytes, identity, connection_id and uuid. The final match arm bails for anything else, i.e. complex algebraic types such as arrays, structs (product types), enums (sum types) and maps.

Source

Thrown at crates/expr/src/lib.rs:374

            value,
            AlgebraicType::I256,
            to_i256,
            AlgebraicValue::I256,
        ),
        AlgebraicType::U256 => parse_int(
            // Parse literal as U256
            value,
            AlgebraicType::U256,
            to_u256,
            AlgebraicValue::U256,
        ),
        AlgebraicType::String => Ok(AlgebraicValue::String(value.into())),
        t if t.is_timestamp() => to_timestamp(),
        t if t.is_bytes() => to_bytes(),
        t if t.is_identity() => to_identity(),
        t if t.is_connection_id() => to_connection_id(),
        t if t.is_uuid() => to_uuid(),
        t => bail!("Literal values for type {} are not supported", fmt_algebraic_type(t)),
    }
}

/// The source of a statement
pub enum StatementSource {
    Subscription,
    Query,
}

/// A statement context.
///
/// This is a wrapper around a statement, its source, and the original SQL text.
pub struct StatementCtx<'a> {
    pub statement: Statement,
    pub sql: &'a str,
    pub source: StatementSource,
}

View on GitHub (pinned to 6dee26c6ef)

Solutions

1. Rewrite the predicate to a supported operation on the complex type (e.g. array containment operators) instead of literal equality.
2. Move the insert/filter logic into a module reducer where values are constructed as typed Rust values.
3. Filter on a scalar column (id, owner, status) and post-filter complex fields client-side.

Example fix

-- before: literal against an array column
SELECT * FROM posts WHERE tags = 'rust';

-- after: use an array operator (or filter on a scalar column)
SELECT * FROM posts WHERE 'rust' <@ tags;
-- or do it in a reducer with typed Rust values

-- inspect column types before writing literal predicates:
spacetime describe my-db
-- avoid literals for array/struct/enum/map columns; only scalars
-- (ints, floats, bool, string, timestamp, bytes, identity, uuid) parse from text

// in Rust client code: build typed values in module reducers instead of SQL text
match compile_sql_stmt(sql, tx, auth) {
    Err(e) if e.to_string().contains("Literal values for type") => {
        // rewrite predicate to array operators or move logic into a reducer
    }
    other => other,
}

When it happens

Trigger: Writing a SQL literal for a column whose schema type is a complex type, e.g. WHERE tags = 'x' where tags is Vec<String>, or an INSERT supplying a text literal for a struct/enum column.

Common situations: Filtering on array or enum columns via the SQL CLI or in subscriptions; hand-writing INSERT statements for tables with product/sum type columns; porting SQL intuitions from relational databases to SpacetimeDB's richer type system.

Related errors

• query returns `{}` but view expects `{}`
• Index '${indexLabel}' on table '${tableLabel}' must define a
• Subscriptions must have at least one query
• Subscriptions must be SQL strings or typed queries
• wrong number of elements

AI-assisted analysis of clockworklabs/SpacetimeDB@6dee26c6ef (2026-08-20). Data as JSON: /api/errors/dddb236f2a0e841a. Report an issue: GitHub.