Exercise 3: A Zero-Match WHERE Clause Returns a Real Empty List — Possible Solution
====================================================================

THE TEST
------------------------------
    db.execute("SELECT * FROM users WHERE age > 100;")
    # table has ages 30, 17, 45 -- none exceed 100

RESULT
------------------------------
    []

A genuine, real Python empty list -- not an error, not None.

TRACING _execute_select TO SEE WHY
------------------------------
    def _execute_select(self, stmt):
        schema, table = self.tables[stmt.table_name]
        column_names = [name for name, col_type in schema.columns]
        for row in table.scan():
            if stmt.where is not None:
                col_name, op, where_value = stmt.where
                idx = column_names.index(col_name)
                if not self.where_applier(row[idx], op, where_value):
                    continue
            yield row

_execute_select is a GENERATOR function (it uses yield). For each of
the three real rows, the for loop runs once: row[idx] is 30, then 17,
then 45, compared against 100 via OPS['>'] = lambda a, b: a > b. All
three comparisons (30 > 100, 17 > 100, 45 > 100) evaluate to False, so
`if not False: continue` fires every single time -- every row is
skipped via `continue`, and `yield row` is never reached for any of
the three rows.

Since the for loop simply runs out of rows to scan (table.scan() is
itself exhausted after the third row), the generator function reaches
its own natural end with no more code to execute -- generators don't
need an explicit "return nothing" or raise an error to signal "I'm
done and produced nothing"; they just stop yielding.

Database.execute()'s own SELECT branch is:

    elif isinstance(stmt, SelectStatement):
        return list(self._execute_select(stmt))

list() applied to a generator that never yielded anything at all
produces exactly [] -- a genuinely empty, but completely valid,
Python list. There's no special-case code anywhere checking "did we
find zero rows? if so, return an error/None instead" -- the empty
result falls out naturally from the same generator-and-list()
machinery that handles the 1-match and 3-match cases too.

WHY THIS WORKS AS AN ANSWER
------------------------------
This confirms zero matches is treated as a perfectly ordinary,
expected outcome of a SELECT query, not an exceptional one -- exactly
matching real SQL semantics, where "no rows matched your WHERE clause"
is an entirely valid, common, and unremarkable result, not something a
real application needs to specifically detect and handle as an error
case.