SQLite: parse the full PRAGMA value grammar - #2469
Open
LucaCappelletti94 wants to merge 2 commits into
Open
Conversation
LucaCappelletti94
marked this pull request as ready for review
August 31, 2026 13:28
iffyio
reviewed
Sep 7, 2026
Comment on lines
+20170
to
+20197
| let span = self.peek_token_ref().span; | ||
| let v = match self.parse_one_of_keywords(&[ | ||
| Keyword::TRUE, | ||
| Keyword::FALSE, | ||
| Keyword::ON, | ||
| Keyword::OFF, | ||
| Keyword::YES, | ||
| Keyword::NO, | ||
| ]) { | ||
| Some(keyword) => Value::Boolean(matches!( | ||
| keyword, | ||
| Keyword::TRUE | Keyword::YES | Keyword::ON | ||
| )) | ||
| .with_span(span), | ||
| None => self.parse_value()?, | ||
| }; | ||
| match &v.value { | ||
| Value::SingleQuotedString(_) => Ok(v), | ||
| Value::DoubleQuotedString(_) => Ok(v), | ||
| Value::Number(_, _) => Ok(v), | ||
| Value::Boolean(_) => Ok(v), | ||
| Value::Placeholder(_) => Ok(v), | ||
| _ => { | ||
| self.prev_token(); | ||
| self.expected_ref("number or string or ? placeholder", self.peek_token_ref()) | ||
| self.expected_ref( | ||
| "boolean, number, string, or ? placeholder", | ||
| self.peek_token_ref(), | ||
| ) |
Contributor
There was a problem hiding this comment.
I think we could simplify the logic to have it accept whatever parse_value returns. and keep the sqlite semantics for validation upstream? that would have avoided this bug in the initial version
Contributor
Author
There was a problem hiding this comment.
I checked SQLite docs hoping for a limited set of allowed values, it states there is explicitly no such set, and I therefore switched to Expr
LucaCappelletti94
force-pushed
the
sqlite-pragma-boolean-values
branch
from
September 7, 2026 05:19
0fa5f24 to
4dfcf28
Compare
LucaCappelletti94
changed the title
LucaCappelletti94
force-pushed
the
sqlite-pragma-boolean-values
branch
from
September 7, 2026 05:23
4dfcf28 to
582c4e4
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
PRAGMAvalues such asjournal_mode = WAL,synchronous = NORMAL,cache_size = -2000andoptimize = 0x10002were rejected. The earlier boolean handling also kept its own keyword list plus a value-type allowlist, and that duplicated allowlist is what rejectedPRAGMA case_sensitive_like = truein the first place.parse_pragma_valuenow follows SQLite's own definition of a pragma value,signed-number | name | signed-literal, and stores the result as anExpr. A bare name likeWALis kept as an identifier, so the parser no longer decides which value a given pragma accepts and leaves that to execution the way SQLite does.parse_pragmabuilds the statement in a single place.This changes
Statement::Pragma.valuefromOption<ValueWithSpan>toOption<Expr>.