risingwavelabs/risingwave · error · ParserError

date/time field

Error message

date/time field

What it means

Raised by `parse_date_time_field` when parsing an INTERVAL literal's unit field. The grammar here only accepts YEAR, MONTH, DAY, HOUR, MINUTE, SECOND (and the plural/quarter/week forms handled above the shown snippet); any other identifier after `INTERVAL` fails and `.expect("date/time field")` yields the error. It means the interval unit keyword is invalid for this dialect.

Source

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

            let value = parser.parse_expr()?;
            Ok((key, value))
        })?;
        self.expect_token(&Token::RBrace)?;
        Ok(Expr::Map { entries })
    }

    // This function parses date/time fields for interval qualifiers.
    pub fn parse_date_time_field(&mut self) -> ModalResult<DateTimeField> {
        dispatch! { peek(keyword);
            Keyword::YEAR => keyword.value(DateTimeField::Year),
            Keyword::MONTH => keyword.value(DateTimeField::Month),
            Keyword::DAY => keyword.value(DateTimeField::Day),
            Keyword::HOUR => keyword.value(DateTimeField::Hour),
            Keyword::MINUTE => keyword.value(DateTimeField::Minute),
            Keyword::SECOND => keyword.value(DateTimeField::Second),
            _ => fail,
        }
        .expect("date/time field")
        .parse_next(self)
    }

    // This function parses date/time fields for the EXTRACT function-like operator. PostgreSQL
    // allows arbitrary inputs including invalid ones.
    //
    // ```
    //   select extract(day from null::date);
    //   select extract(invalid from null::date);
    //   select extract("invaLId" from null::date);
    //   select extract('invaLId' from null::date);
    // ```
    pub fn parse_date_time_field_in_extract(&mut self) -> ModalResult<String> {
        let checkpoint = *self;
        let token = self.next_token();
        match token.token {
            Token::Word(w) => Ok(w.value.to_uppercase()),
            Token::SingleQuotedString(s) => Ok(s.to_uppercase()),

View on GitHub (pinned to 6469eb736d)

Solutions

  1. Use a supported unit: YEAR, MONTH, DAY, HOUR, MINUTE, SECOND (and the other recognized fields such as QUARTER/WEEK if listed above the snippet).
  2. Rewrite unsupported units into supported ones, e.g. `INTERVAL '2 weeks'` -> `INTERVAL 14 DAY`.
  3. Validate user-supplied interval units against the allowed set before interpolating into SQL.

Example fix

// before
SELECT now() + INTERVAL 1 FORTNIGHT;
// after
SELECT now() + INTERVAL 14 DAY;
Defensive patterns

Strategy: validation

Validate before calling

const FIELDS = new Set(['YEAR','MONTH','DAY','HOUR','MINUTE','SECOND','QUARTER','WEEK']);
function validIntervalField(u) { return FIELDS.has(u.toUpperCase()); }

Type guard

const isDateTimeField = (s) => typeof s === 'string' && ['YEAR','MONTH','DAY','HOUR','MINUTE','SECOND','QUARTER','WEEK'].includes(s.toUpperCase());

Prevention

When it happens

Trigger: Parsing `INTERVAL <n> <unit>` where unit is not a recognized date/time field, e.g. `INTERVAL 1 FORTNIGHT`, `INTERVAL 5 DAYS` in a dialect that only accepts DAY, or a misspelled unit like `INTERVAL 1 MOTH`.

Common situations: Porting interval literals from other SQL engines with extra units (FORTNIGHT, DECADE); typos in interval units; programmatic SQL generation building interval strings from user input.

Understand the failure class

Background: Invalid enum value errors: "Unknown type", "Invalid scope", "must be one of" — when a string is not on the library's allowed list — this error's family across 23 libraries.

Related errors


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