Mode disclosure
All modes use one coherent workspace; only disclosure and guidance change. Learn mode keeps theory, concept names, full schema help, progressive hints, and solution review available.
Scalar and Set Subqueries / predict result
M21-A02 - Prediction - identify when a scalar subquery returns too many rows
M21-A02 - Prediction - identify when a scalar subquery returns too many rows. Use nested queries when scalar or one-column set shape is clearest.
- Result grain
- one scalar-shape prediction for a deliberately unsafe subquery
- Exact columns
- scalar_test; subquery_rows; predicted_result
SQL editor shortcuts: Ctrl or Command Enter runs the query, Ctrl or Command Shift Enter checks it, Alt H opens the next hint, Ctrl or Command slash toggles a line comment, Ctrl or Command Shift F formats the SQL, and Escape closes transient UI.
Cursor at line 1, column 1.
Scenario
Use nested SELECTs deliberately: distinguish scalar one-value subqueries from one-column set subqueries, stage derived tables, and keep each subquery population explicit.
Scalar and Set Subqueries / predict result
One-sentence task
M21-A02 - Prediction - identify when a scalar subquery returns too many rows. Use nested queries when scalar or one-column set shape is clearest.
Learn mode disclosure
Theory, concept names, full schema help, and progressive hints are available.
Structured output contract
- Result grain
- one scalar-shape prediction for a deliberately unsafe subquery
- Exact columns
- scalar_test; subquery_rows; predicted_result
- Source population
- Use the prompt setup plus FROM, JOIN, WHERE, and subquery predicates as the source population. Visible rows are only examples.
- Grouping
- Group only at the requested output grain: one scalar-shape prediction for a deliberately unsafe subquery.
- Ordering
- No display order requirement unless Check reports one.
- Validation
- select-only; hidden deterministic variants.
Relevant tables
Time and difficulty
- Estimated time
- 7 minutes
- Difficulty
- 4/5
Objective and concepts
State the requested SQL output contract for scalar and set subqueries using source grain, columns, ordering, and edge-case evidence.
Glossary links
Concept material
SQL Trail treats every query as an evidence trail: identify source grain, transform rows deliberately, then compare output to a shared contract.
A passing query must handle hidden nulls, ties, boundaries, and no-match rows when the contract makes them relevant.
Syntax card
SELECT <requested_columns>
FROM <source_table>
WHERE <source_population_filter>
GROUP BY <result_grain_columns>
ORDER BY <deterministic_tie_breakers>;- <requested_columns> means the exact output columns, aliases, and order from the visible contract.
- <source_population_filter> means the row population definition, not a copied visible-row value.
- <deterministic_tie_breakers> means all ordering and tie rules needed for repeatable output.
Why this works
The nested AVG query returns one value, so the outer WHERE clause can compare each product row to that scalar result.
Edge cases
Hidden variants preserve nulls, ties, duplicates, boundaries, no-match rows, and alternate row order when those risks apply.
PostgreSQL note
The local engine uses PostgreSQL-compatible syntax, including explicit NULL predicates, deterministic ORDER BY clauses, and transactional grading.
Worked example
SELECT product_id, product_name, current_price FROM products WHERE current_price > (SELECT AVG(current_price) FROM products) ORDER BY product_id;Assumptions, dialect notes, and common traps
- Duplicate policy
- Preserve duplicate facts unless the prompt explicitly asks for distinct tuples or set semantics.
- Null policy
- Preserve NULL, empty string, zero, and false as distinct values unless the contract says to display a fallback.
- Tie-breakers
- Use every ordering rule in the contract and end tied business metrics with deterministic secondary keys when needed.
- Zero-related entities
- Do not invent zero rows unless the contract asks for preserved parents, missing entities, or complete periods.
- Numeric tolerance
- Use exact semantic comparison unless the activity explicitly declares a numeric tolerance.
PostgreSQL-compatible local checks
Queries run in a local PGlite worker with PostgreSQL-style syntax and transactional grading.
- Scalar means one value: A detail subquery is placed where equality or comparison expects one result. Repair: Use an aggregate or another predicate so the nested SELECT returns one value for scalar comparison.
- Outer filters do not leak inward: The outer query filters active rows, but the nested average still includes inactive rows. Repair: Repeat the intended population filter inside the subquery.
- IN needs one comparable column: The set subquery returns two columns because both look useful for debugging. Repair: Return only the key column being compared by the IN predicate.
- Membership is not payload: A join is used only to test related-row presence, causing duplicates or unnecessary columns. Repair: Use a set subquery for membership and reserve joins for related columns that must appear in output.
Opened hints
No hints opened yet.