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 01
DATE stores a calendar day (2024-02-15) with no time. TIMESTAMP stores a day and a time (2024-02-15 14:30:00). orders.order_date holds dates only. A date literal is written DATE '2024-02-15' or CAST('2024-02-15' AS DATE); both are clear to PostgreSQL. Dates compare with =, <, <=, >, >= like numbers: a later date is greater.
You can do arithmetic: order_date + 7 gives the date seven days later. When a DATE meets a TIMESTAMP in a comparison, the date is treated as midnight at the start of that day (2024-02-15 00:00:00), so '2024-02-15 10:00' is later than the date 2024-02-15.
These lessons use fixed dates only. Do not use CURRENT_DATE or now() — the result would change every day and grading could not be predictable.
Common mistakes: comparing with text that is not an ISO date ('15/02/2024'); mixing up > and >= right on the boundary; expecting a DATE to carry a time.
Small example:
SELECT id, order_date FROM orders WHERE order_date >= DATE '2024-03-01';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, order_date · row order is not required
Expected result (displayed data):
Loading…DATE stores a calendar day (2024-02-15) with no time. TIMESTAMP stores a day and a time (2024-02-15 14:30:00). orders.order_date holds dates only. A date literal is written DATE '2024-02-15' or CAST('2024-02-15' AS DATE); both are clear to PostgreSQL. Dates compare with =, <, <=, >, >= like numbers: a later date is greater. You can do arithmetic: order_date + 7 gives the date seven days later. When a DATE meets a TIMESTAMP in a comparison, the date is treated as midnight at the start of that day (2024-02-15 00:00:00), so '2024-02-15 10:00' is later than the date 2024-02-15. These lessons use fixed dates only. Do not use CURRENT_DATE or now() — the result would change every day and grading could not be predictable. Common mistakes: comparing with text that is not an ISO date ('15/02/2024'); mixing up > and >= right on the boundary; expecting a DATE to carry a time.
QUERY STANDBY
›