Code Lab is in development. New lessons and improvements are on the way. Progress can be deleted.
Loading…
Code Lab is in development. New lessons and improvements are on the way. Progress can be deleted.
Loading…
Code Lab is in development. New lessons and improvements are on the way. Progress can be deleted.
SQL / POSTGRESQL / Learn / LESSON 05
A correlated subquery uses a column of the outer row — for example WHERE o2.customer_id = o.customer_id. Logically it runs once per outer row with that row's values. That answers questions such as "this customer's largest order" or "above the average of the row's own customer".
Give the outer and inner tables different aliases (o and o2); otherwise a column is compared with itself. A scalar correlated subquery in SELECT returns NULL when the row has no matches (for example a customer without orders).
Note: "once per row" is the logical reading, not a promise about how PostgreSQL executes it internally. A NULL key never matches in a correlated condition: NULL = NULL is not true.
Common mistakes: the same alias on both levels; a missing link condition; expecting 0 instead of NULL when nothing matches.
Small example:
SELECT c.id, (SELECT COUNT(*) FROM orders o WHERE o.customer_id = c.id) AS orders_count FROM customers c;
Working tables for this task. Grading also uses other datasets with the same schema.
| id | name | category | price |
|---|---|---|---|
| 1 | Atlas | books | 30 |
| 2 | Novel | books | 15 |
| 3 | Comic | books | 14.99 |
| 4 | Lamp | home | 29.99 |
| 5 | Vase | home | 30 |
| 6 | Rug | home | 45 |
| 7 | Hammer | tools | 15 |
| 8 | Drill | tools | 60 |
| 9 | Tape | tools | 15 |
| 10 | Candle | NULL | 8.5 |
| 11 | Gift Card | NULL | 25 |
| id | name | city |
|---|---|---|
| 1 | Mira | Sofia |
| 2 | Niko | Varna |
| 3 | Iva | Sofia |
| 4 | Alex | NULL |
| 5 | Boris | Plovdiv |
| 6 | Lena | Varna |
| 7 | Petya | Sofia |
| id | customer_id | total | order_date |
|---|---|---|---|
| 1 | 1 | 120 | 2024-01-05 |
| 2 | 1 | 35.5 | 2024-01-20 |
| 3 | 2 | 40 | 2024-01-20 |
| 4 | 3 | 99.99 | 2024-01-31 |
| 5 | NULL | 60 | 2024-02-01 |
| 6 | 1 | 40 | 2024-02-01 |
| 7 | 2 | 75.25 | 2024-02-14 |
| 8 | 3 | 100 | 2024-02-15 |
| 9 | 5 | 22 | 2024-02-15 |
| 10 | 1 | 39.99 | 2024-02-29 |
| 11 | 2 | 55 | 2024-03-01 |
| 12 | 3 | 18 | 2024-03-10 |
| 13 | 1 | 130 | 2024-03-15 |
| 14 | 2 | 40 | 2024-03-15 |
| 15 | 2 | 12.5 | 2024-03-31 |
| 16 | 3 | 47 | 2024-04-01 |
Expected columns: id, name, largest_order · row order is not required
Expected result (displayed data):
Loading…A correlated subquery uses a column of the outer row — for example WHERE o2.customer_id = o.customer_id. Logically it runs once per outer row with that row's values. That answers questions such as "this customer's largest order" or "above the average of the row's own customer". Give the outer and inner tables different aliases (o and o2); otherwise a column is compared with itself. A scalar correlated subquery in SELECT returns NULL when the row has no matches (for example a customer without orders). Note: "once per row" is the logical reading, not a promise about how PostgreSQL executes it internally. A NULL key never matches in a correlated condition: NULL = NULL is not true. Common mistakes: the same alias on both levels; a missing link condition; expecting 0 instead of NULL when nothing matches.
QUERY STANDBY
›