Exercise 2: A Query With No WHERE Clause Parses Correctly — Possible Solution
====================================================================

THE TEST
------------------------------
    stmt = Parser(tokenize("SELECT * FROM users;")).parse_statement()
    stmt.where

RESULT
------------------------------
    SelectStatement('users', None)
    stmt.where -> None

The statement parses successfully, with where explicitly set to None
rather than raising an error for the "missing" clause.

WHICH CHECK MAKES THE WHERE CLAUSE OPTIONAL
------------------------------
parse_select's own relevant lines are:

    where = None
    if self.peek() is not None and self.peek().kind == 'KEYWORD' and self.peek().text == 'WHERE':
        self.advance()
        col = self.expect('IDENT').text
        op = self.expect('OP').text
        val_tok = self.advance()
        val = int(val_tok.text) if val_tok.kind == 'NUMBER' else val_tok.text
        where = (col, op, val)
    if self.peek() is not None and self.peek().text == ';':
        self.advance()
    return SelectStatement(table_name, where)

`where` is initialized to None BEFORE the WHERE-clause check ever
runs. The entire block that parses a real WHERE clause is guarded by
an `if` condition testing whether the very next token is genuinely the
keyword WHERE. For "SELECT * FROM users;", after consuming SELECT, *,
FROM, and the table name "users", the next token is the punctuation
';' -- not a WHERE keyword -- so `self.peek().text == 'WHERE'`
evaluates to False, and the entire indented block (everything that
would parse the column/operator/value) is skipped entirely. `where`
is never reassigned away from its initial None value, and the
function proceeds straight to checking for (and consuming) the
trailing semicolon.

WHY THIS WORKS AS AN ANSWER
------------------------------
This confirms the WHERE clause's own optionality isn't handled by a
try/except around a failed parse attempt, or by peeking further ahead
speculatively -- it's a single, simple, up-front conditional check on
the very next token. If that token isn't literally the WHERE keyword,
the parser correctly concludes there's no WHERE clause present at all
and moves on, exactly matching how a real SQL SELECT statement is
allowed to omit its own WHERE clause entirely and still be a
completely valid, meaningful query (one that simply selects every row).