The login form already validated that an email was typed. Complete the SELECT so it returns only that customer's id, email, and display name. Do not return every customer, and do not invent extra columns.
Requirements
Keep the supplied CREATE TABLE and INSERT statements unchanged.
Return exactly customer_id, email, and display_name in that order.
Match email = 'ada@example.com' exactly.
Do not use LIKE, LIMIT, or SELECT *.
Do not return Grace, Alonzo, or O'Brien.
Leave the unique email constraint in place; do not add a second Ada row.
Example
Input
Keep the customers table, then select Ada by the exact email in the prompt.
A login lookup is not a browse. SELECT * would leak columns the form never asked for, and omitting WHERE would return every account. Equality on the unique email is the whole contract: one key, one row, three named columns. Ada O'Brien's address is a different string, so it must not match. In an application you would bind the form value as a parameter instead of pasting it into SQL; this exercise still uses a literal because the runner cannot bind host variables. The skill is the same shape: fixed SQL text, a value in the predicate, and a narrow result.
Why this pattern matters
Account lookup is the first query many apps ship. If it returns the wrong Ada, or every column on customers, you have already mixed identity with a dump.
Solution walkthrough
List customer_id, email, display_name.
WHERE email = 'ada@example.com' with equality, not LIKE 'ada%'.
Confirm Ada O'Brien remains unmatched.
Common mistakes to avoid
LIKE 'ada%' matching ada.obrien@example.com.
SELECT * including columns the login never needed.
Forgetting quotes around the email literal.
What this exercise teaches
Project a narrow column list
Filter with an equality predicate
Treat email as a unique lookup key
A PRACTICAL PLAN
Work through Look up one customer by email with intent.
Translate the contract.Turn the requirements into a short checklist before editing your-solution.sql.
Use the example as evidence.Predict the result for the supplied input, then add one boundary case such as an empty value, a limit, or unexpected input.
Review the implementation.Compare your choices against solution.sql only after a real attempt.
EXERCISE FAQ
Before you move on.
What does “Look up one customer by email” teach?
This beginner SQL exercise focuses on Project a narrow column list, Filter with an equality predicate, Treat email as a unique lookup key. Its requirements define the exact behavior to implement before you write code.
How should I validate this SQL solution?
Start with the displayed example input and expected output, then test a boundary case suggested by the requirements. Open your-solution.sql and select Run code. The browser creates a fresh isolated SQLite database, executes the complete script, and compares its result rows with the expected report.
When should I open the reference solution?
Attempt Look up one customer by email first. Then open the read-only solution file to compare the contract, edge-case handling, and implementation choices—not simply to copy the final code.
