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.
IN, BETWEEN, and Range Semantics / write query
M07-A04 - Write - implement an inclusive numeric band
M07-A04 - Write - implement an inclusive numeric band. Express membership, inclusive ranges, and half-open alternatives deliberately.
- Result grain
- one product row inside the inclusive stock-count band
- Exact columns
- product_id; product_name; stock_count
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
Express list membership and ranges precisely: refactor repeated equality with IN, treat BETWEEN endpoints as inclusive, and choose half-open timestamp bounds when the period demands it.
IN, BETWEEN, and Range Semantics / write query
One-sentence task
M07-A04 - Write - implement an inclusive numeric band. Express membership, inclusive ranges, and half-open alternatives deliberately.
Learn mode disclosure
Theory, concept names, full schema help, and progressive hints are available.
Structured output contract
- Result grain
- one product row inside the inclusive stock-count band
- Exact columns
- product_id; product_name; stock_count
- Source population
- Use the prompt setup plus FROM, JOIN, WHERE, and subquery predicates as the source population. Visible rows are only examples.
- Grouping
- Do not collapse rows unless the contract explicitly asks for aggregation, distinct tuples, or set semantics.
- Ordering
- order by stock_count then product_id
- Validation
- select-only; hidden deterministic variants.
Relevant tables
Time and difficulty
- Estimated time
- 7 minutes
- Difficulty
- 2/5
Objective and concepts
Debug the requested SQL output contract for in, between, and range semantics 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
BETWEEN keeps both the lower stock boundary and the upper stock boundary while excluding adjacent outside values.
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, stock_count FROM products WHERE stock_count BETWEEN 3 AND 11 ORDER BY stock_count, 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.
- IN lists contain values: The column name is repeated inside the IN list or mixed with literal values. Repair: Write the source column once before IN, then list only quoted text values or typed literals inside parentheses.
- BETWEEN includes both endpoints: Rows exactly on the lower or upper bound are excluded as if BETWEEN were exclusive. Repair: Treat BETWEEN a AND b as >= a and <= b for scalar values.
- NOT IN is not automatically null-safe: A missing candidate value is expected to behave like a normal value in anti-list logic. Repair: Keep NULL handling explicit; this module flags the warning before later anti-join and null lessons.
- Timestamp periods need the next boundary: A date-time period ends at a guessed 23:59:59 value and misses later precision. Repair: Use >= period_start and < next_period_start for half-open timestamp periods.
Opened hints
No hints opened yet.