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
- Use a supported unit: YEAR, MONTH, DAY, HOUR, MINUTE, SECOND (and the other recognized fields such as QUARTER/WEEK if listed above the snippet).
- Rewrite unsupported units into supported ones, e.g. `INTERVAL '2 weeks'` -> `INTERVAL 14 DAY`.
- 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
- Validate user-supplied interval units against the supported set before string interpolation.
- Convert unsupported units (fortnight, decade) to supported ones at generation time.
- Never build INTERVAL literals directly from free-form user input.
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.