Exercise 1: Reproducing the eval() Bug Through the Full Database Pipeline — Possible Solution
====================================================================

THE TEST
------------------------------
    db_naive = Database(tempfile.mkdtemp(), where_applier=apply_where_naive)
    db_naive.execute("CREATE TABLE users (id INTEGER, name TEXT, age INTEGER);")
    db_naive.execute("INSERT INTO users VALUES (1, 'Alice', 30);")
    db_naive.execute("SELECT * FROM users WHERE age = 30;")

RESULT
------------------------------
    SyntaxError: invalid syntax

The exact same failure the isolated apply_where_naive(5, '=', 5) test
produced, now reproduced by running a real, complete query string
through the full CREATE / INSERT / SELECT pipeline.

WHY THE FULL PIPELINE FAILS THE SAME WAY
------------------------------
_execute_select's own filtering line is:

    if not self.where_applier(row[idx], op, where_value):
        continue

Database was constructed with where_applier=apply_where_naive, so this
line calls apply_where_naive(30, '=', 30) once the scan reaches the
one real row that was inserted. That call builds the exact same kind
of string this chapter's own isolated test built --
f"{row_value!r} {op} {where_value!r}" becomes "30 = 30" -- and hands
it to eval(), which raises the identical SyntaxError, for the
identical reason: '=' is Python's assignment operator, not its
equality operator, and eval() only ever accepts expressions.

WHY THIS WORKS AS AN ANSWER
------------------------------
This confirms the bug isn't an artifact of how apply_where_naive
happened to be tested in isolation -- it's a genuine, real failure
that occurs the moment a real user (or a real application) tries to
run one of the most ordinary SQL queries imaginable through this
engine. Testing a bug both in isolation (a focused, minimal
reproduction) AND through the full, real system it lives inside (a
realistic, end-to-end reproduction) is valuable for a specific reason:
the isolated test proves exactly WHERE the mistake lives, while the
end-to-end test proves it actually matters in practice, not just in a
contrived unit test that might never be exercised by real usage.