Brightlane's shipping operations manager is building a weekly progress report that covers all orders still in the fulfillment pipeline.
Write a query to return the ID and current status of every order that has not yet reached delivered status.
Assumptions:
- The
orderstable contains every order Brightlane has processed. - The
statuscolumn records the order's current stage; delivered orders havestatusset to'delivered'. - All other status values represent orders still in the pipeline.
Output:
- One row per qualifying order, with columns
idandstatus.
Schema · ecommerce 5 tables
Run previews · Check grades
Write a query, then run it to see results here.
Worked solution Try it yourself first
SELECT
id,
status
FROM
orders
WHERE
status <> 'delivered'The shape
The <> operator inverts equality — keep every row whose status is anything other than 'delivered'. One small operator change covers pending, shipped, and cancelled in a single filter.
Clause by clause
SELECT id, statusreturns the order identifier and its current pipeline stage. Pullingstatusinto the output lets the report show why each order is still open, not just that it is.FROM ordersis the source — every order Brightlane has processed, in every stage of its lifecycle.WHERE status <> 'delivered'keeps every row whosestatusis not exactly the string'delivered'. PostgreSQL evaluates the inequality once per row; rows where the values are equal drop out, every other row passes through.
Why <> and not enumerate the other statuses
The alternative is to write a filter that lists each acceptable status — WHERE status = 'pending' OR status = 'shipped' OR status = 'cancelled'. Both shapes return the same rows today, but they answer different questions. <> says "anything that isn't delivered." The enumerated list says "specifically these three."
The difference matters when the data changes. If Brightlane adds a new pipeline status — processing, say, or held — the <> filter picks it up automatically because the new status isn't 'delivered'. The enumerated list silently misses it; the new rows just never appear in the weekly report, and nobody notices until a complaint surfaces. "Not delivered" is the business definition of "still in the pipeline," so the filter that encodes that definition directly is the more durable shape.
This also makes the query easier to read out loud. WHERE status <> 'delivered' matches the prompt's wording — "has not yet reached delivered status" — almost word for word. Code that reads like the request is code that's easier to audit later.
The trap
NULL ruins not-equal comparisons silently. If any row has status set to NULL — no value recorded yet — then status <> 'delivered' evaluates to neither true nor false for that row; it evaluates to unknown, and unknown does not satisfy WHERE. The row is dropped from the result, even though intuitively a NULL status is clearly not 'delivered'. The next node covers the rule that handles NULL the way the analyst would expect. For now: <> filters silently exclude rows where the compared column is NULL, and the report is only complete if the column never holds NULL — or if the missing rows are added back with the technique that comes next.
You practiced the not-equal filter (<>) to exclude one specific value while keeping everything else. Inverse filters are the recurring shape whenever 'not X' is more concise than enumerating each acceptable value.
