Brightlane's logistics team is preparing an itemized cost breakdown for a single shipment, ahead of invoicing the customer. The shipment carries three charges: a fuel surcharge of $18.50, a handling fee of $7.25, and an insurance charge of $4.00.
Write a query to return each charge alongside the total shipping cost in a single row.
Output:
- A single row with four columns, in this order:
fuel_surcharge,handling_fee,insurance, andtotal_cost.
Run previews · Check grades
Write a query, then run it to see results here.
Worked solution Try it yourself first
SELECT
18.50 AS fuel_surcharge,
7.25 AS handling_fee,
4.00 AS insurance,
18.50 + 7.25 + 4.00 AS total_cost The shape
Three labeled literal charges and a total expression that adds them up, all returned as four columns in a single row.
Clause by clause
18.50 AS fuel_surcharge,7.25 AS handling_fee, and4.00 AS insuranceare three labeled numeric literals. Each one is a straight value from the shipment manifest, withASnaming the column so the row reads as an itemized invoice rather than four anonymous numbers. The columns come back in the same order they're written in theSELECTlist, which is what lets the result feed straight into an invoice template without any post-processing.18.50 + 7.25 + 4.00 AS total_costis the roll-up. Each operand carries two decimal places, so PostgreSQL preserves that scale through the additions and returns29.75with the same precision the inputs had. There's no rounding step; the result of adding numerics whose scales match is exact.
Why this and not just add the named columns
The breakdown columns — fuel_surcharge, handling_fee, and insurance — can't be referenced from inside the total_cost expression. Every expression in the SELECT list evaluates against the same input at the same time, and aliases come into being only after the whole SELECT finishes. By then the row is already on its way out, so the total has to be written from the underlying literals.
Repeating the literals is the trade-off. The four columns share the same source numbers; writing them twice is the cost of producing the breakdown and the total side by side in a single row. When everything has to live inside a single SELECT list, computing the same numbers more than once is part of the shape.
You practiced returning the components of a sum alongside the sum itself. The breakdown-plus-total shape recurs anywhere a query shows both detail and roll-up in the same row.