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.
EXISTS, NOT EXISTS, and Correlation / guided completion
M22-A05 - NOT IN lab - observe unknown behavior when the set contains NULL
M22-A05 - NOT IN lab - observe unknown behavior when the set contains NULL. Express presence and absence with correlated existence tests and null-safe anti-logic.
- Result grain
- one customer with NOT IN and NOT EXISTS anti-presence outcomes
- Exact columns
- customer_id; customer_name; referred_by_customer_id; not_in_result; not_exists_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
Express presence and absence with correlated EXISTS and NOT EXISTS tests, distinguish Boolean intent from selected payload, and avoid nullable NOT IN traps.
EXISTS, NOT EXISTS, and Correlation / guided completion
One-sentence task
M22-A05 - NOT IN lab - observe unknown behavior when the set contains NULL. Express presence and absence with correlated existence tests and null-safe anti-logic.
Learn mode disclosure
Theory, concept names, full schema help, and progressive hints are available.
Structured output contract
- Result grain
- one customer with NOT IN and NOT EXISTS anti-presence outcomes
- Exact columns
- customer_id; customer_name; referred_by_customer_id; not_in_result; not_exists_result
- 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 customer_id
- Validation
- select-only; hidden deterministic variants.
Relevant tables
Time and difficulty
- Estimated time
- 10 minutes
- Difficulty
- 4/5
Objective and concepts
Debug the requested SQL output contract for exists, not exists, and correlation 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
When the related table only proves presence, EXISTS communicates intent without relying on DISTINCT to undo one-to-many joins.
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 query_shape, customer_rows FROM (VALUES ('exists', (SELECT COUNT(*)::int FROM (SELECT c.customer_id FROM customers c WHERE EXISTS (SELECT 1 FROM orders o WHERE o.customer_id = c.customer_id AND o.status = 'completed')) exists_rows)), ('join_distinct', (SELECT COUNT(*)::int FROM (SELECT DISTINCT c.customer_id FROM customers c JOIN orders o ON o.customer_id = c.customer_id WHERE o.status = 'completed') join_rows))) AS comparison(query_shape, customer_rows) ORDER BY query_shape;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
- Preserve requested zero-related, no-match, or complete-period entities and make display fallback explicit.
- 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.
- EXISTS needs correlation: Every outer row qualifies because the inner query finds any matching row anywhere. Repair: Add the outer-to-inner key predicate inside the EXISTS or NOT EXISTS subquery.
- EXISTS ignores selected payload: Changing SELECT 1 to SELECT star is expected to change which outer rows qualify. Repair: Treat EXISTS as a Boolean presence test; the inner SELECT list is only payload syntax.
- NOT IN is not null-safe: An anti-match query returns no rows when the subquery set contains NULL. Repair: Use NOT EXISTS with a correlated predicate when nullable values can appear.
- DISTINCT can hide duplicate children: A join creates duplicate parent rows and DISTINCT is used as the main repair. Repair: Use EXISTS when the child table only proves presence and contributes no output columns.
Opened hints
No hints opened yet.