risingwavelabs/risingwave · error · ParserError

parameter value

Error message

parameter value

What it means

Raised while parsing a SET VARIABLE statement's single value: after the variable name and '=', the parser expects a literal or identifier, and the `fail.expect("parameter value")` branch fires when neither matches. If the token is the identifier 'default', a related cut error 'parameter list value' is raised instead. The message reports that a valid SET value was required but absent.

Source

Thrown at src/sqlparser/src/parser.rs:3134

    fn parse_config_param_no_list(&mut self) -> ModalResult<ConfigParam> {
        self.parse_config_param_inner(Self::parse_set_variable_no_list)
    }

    fn parse_set_variable_no_list(&mut self) -> ModalResult<SetVariableValue> {
        alt((
            Keyword::DEFAULT.value(SetVariableValue::Default),
            alt((
                Self::ensure_parse_value.map(SetVariableValueSingle::Literal),
                |parser: &mut Self| {
                    let checkpoint = *parser;
                    let ident = parser.parse_identifier()?;
                    if ident.value == "default" {
                        *parser = checkpoint;
                        return parser.expected("parameter list value").map_err(|e| e.cut());
                    }
                    Ok(SetVariableValueSingle::Ident(ident))
                },
                fail.expect("parameter value"),
            ))
            .map(|single: SetVariableValueSingle| SetVariableValue::Single(single)),
        ))
        .parse_next(self)
    }

    pub fn parse_since(&mut self) -> ModalResult<Since> {
        if self.parse_keyword(Keyword::SINCE) {
            let checkpoint = *self;
            let token = self.next_token();
            match token.token {
                Token::Word(w) => {
                    let ident = w.to_ident()?;
                    // Backward compatibility for now.
                    if ident.real_value() == "proctime" || ident.real_value() == "now" {
                        self.expect_token(&Token::LParen)?;
                        self.expect_token(&Token::RParen)?;
                        Ok(Since::ProcessTime)

View on GitHub (pinned to 6469eb736d)

Solutions

1. Provide a simple literal or identifier after '=', e.g. `SET x = 'value'` or `SET x = 42`.
2. Remove complex expressions; precompute the value in the client and set the literal.
3. Check the dialect's SET statement grammar and rewrite unsupported forms (TO, expressions, lists).

Example fix

// before
SET my_timeout = 30 * 1000;
// after
SET my_timeout = 30000;

// SET value must be a simple literal or identifier
function validSetValue(v) { return typeof v === 'number' || typeof v === 'string' || /^[A-Za-z_][A-Za-z0-9_]*$/.test(v); }

try { run(sql); } catch (e) { if (String(e).includes('parameter value')) { rewriteToLiteralSet(sql); } else { throw e; } }

When it happens

Trigger: Parsing `SET <var> = <bad-token>` where the right-hand side is not a number, string, or identifier — e.g. `SET x = ;`, `SET x = (1)`, or an expression like `SET x = 1 + 2`.

Common situations: Session-variable scripts ported from other engines whose SET syntax supports expressions; truncated SQL from string concatenation; drivers sending dialect-specific SET forms (e.g. `SET x TO ...` variants).

Understand the failure class

Background: "Invalid ... format", "must be in format X", "does not look like a ..." — invalid argument format errors across CLI tools and libraries — this error's family across 17 libraries.

Related errors

• {0}
• ROWS, RANGE, or GROUPS
• BOTH, LEADING, or TRAILING
• date/time field
• backfill order strategy

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