rustfs/rustfs · error · SelectError

IncorrectSqlFunctionArgumentType

IncorrectSqlFunctionArgumentType

Error message

An incorrect argument type was specified in a function call in the SQL expression.

What it means

SelectError::IncorrectSqlFunctionArgumentType is produced by the planner error classifier (crates/s3select-query/src/sql/planner.rs:84-96): DataFusion plan errors matching "Failed to coerce arguments to satisfy a call to ..." or "Function '...' failed to match any signature" are reclassified to it. A function call's arguments could not be coerced to any signature of that function.

Source

Thrown at crates/s3select-api/src/lib.rs:106

    #[error("An error occurred while parsing the CSV file. Check the file and try again.")]
    CsvParsingError,

    #[error("An error occurred while parsing the JSON file. Check the file and try again.")]
    JsonParsingError,

    #[error("An error occurred while parsing the Parquet file. Check the file and try again.")]
    ParquetParsingError,

    #[error("{message}")]
    ParseSelectFailure { message: String },

    #[error("The SQL expression is invalid.")]
    InvalidQuery,

    #[error("The SQL expression contains a data type that is not valid.")]
    InvalidDataType,

    #[error("An incorrect argument type was specified in a function call in the SQL expression.")]
    IncorrectSqlFunctionArgumentType,

    #[error("The data source path in the SQL expression is not supported.")]
    DataSourcePathUnsupported,

    #[error("Unsupported S3 Select SQL structure: {message}")]
    UnsupportedSqlStructure { message: String },

    #[error("We encountered an unsupported SQL operation.")]
    UnsupportedSqlOperation,

    #[error("A column name or a path provided does not exist in the SQL expression.")]
    EvaluatorBindingDoesNotExist,

    #[error("The field name matches to multiple fields in the file. Check the SQL expression and the file, and try again.")]
    AmbiguousFieldName,

    #[error("The value of a parameter in ScanRange element is invalid. Check the service API documentation and try again.")]

View on GitHub (pinned to 35af688cd9)

Solutions

  1. CAST each argument to the function's documented parameter type
  2. Check the column's inferred type from the file schema before writing the expression
  3. Prefer explicit literals/casts over relying on implicit coercion

Example fix

-- before: SUBSTRING on a numeric column
SELECT SUBSTRING(order_id FROM 1 FOR 2) FROM S3Object;

-- after
SELECT SUBSTRING(CAST(order_id AS VARCHAR) FROM 1 FOR 2) FROM S3Object;
Defensive patterns

Strategy: validation

Validate before calling

// Check argument types against the inferred schema before sending the query.
let schema = infer_object_schema(&key).await?; // from header or sampling
for call in extract_function_calls(&request.expression) {
    for arg in call.args {
        let ty = resolve_type(&arg, &schema)?;
        ensure_coercible(&ty, &call.expected_arg_types)?;
    }
}

Try / catch

match select_object_content(req).await {
    Ok(resp) => { /* records */ }
    Err(e) if matches!(e.select_error(), SelectError::IncorrectSqlFunctionArgumentType) => {
        // Add explicit CASTs so each argument matches the function signature, then resend.
    }
    Err(e) => return Err(e),
}

Prevention

When it happens

Trigger: Calling a SQL function with arguments of the wrong type: string functions on numeric columns without CAST, SUBSTRING with non-integer bounds, date functions on untyped strings, literals that infer to an unexpected type.

Common situations: Column types differing from what the expression assumes (VARCHAR vs INT); examples copied from another dialect; implicit-conversion expectations from loosely typed engines.

Related errors


AI-assisted analysis of rustfs/rustfs@35af688cd9 (2026-08-20). Data as JSON: /api/errors/7966853d6ffa9f78. Report an issue: GitHub.