A tax system calculates liability on gross profit, not on total revenue. For one period, revenue was $8,000 and cost was $3,000. The tax rate on gross profit is 20%.
Write a query to return the tax amount owed in a single column named tax_amount.
Output:
- A single row with one column,
tax_amount, containing the calculated liability.
Run previews · Check grades
Write a query, then run it to see results here.
Worked solution Try it yourself first
SELECT
(8000 - 3000) * 0.20 AS tax_amountThe shape
The parentheses force the gross profit to be computed first — revenue minus cost — and the tax rate then applies to that difference. Without them, the tax would scale only the cost, which is a completely different calculation.
Clause by clause
SELECT (8000 - 3000) * 0.20runs the parenthesised subtraction first:8000 - 3000returns5000, the gross profit for the period. The multiplication then applies the 20% tax rate to that figure and returns1000. The decimal0.20makes the rate anumeric, and PostgreSQL promotes the integer subtotal to match, so the calculation runs in decimal arithmetic. The exact result is1000.00, which the audit will read as a dollar liability.AS tax_amountlabels the column as the figure the tax system needs. The result reads as a dollar amount, not a math expression.
Why this and not 8000 - 3000 * 0.20
Strip the parentheses and operator precedence rewrites the calculation. 3000 * 0.20 resolves first to 600.00, and the subtraction returns 7400.00. That number has no meaning in the prompt's business logic. It's neither the tax owed nor any other figure the system would report; it's revenue minus 20% of the cost, which is not a calculation anyone is asking for. But it looks plausible enough that a reconciliation might let it through.
The parentheses encode the prompt's rule — "the tax is calculated on gross profit" — into the SQL evaluation order. The shape (revenue - cost) * rate recurs everywhere: tax on gross profit, discount on subtotal after credits, fee on balance after deductions. Whenever a rate applies to a difference rather than to a single value, the difference has to be parenthesised first.
The trap
A missing pair of parentheses changes which value the rate scales without producing any error. The query runs, the result type is right (a dollar amount with the expected number of decimal places), and the figure looks like it could plausibly be the tax owed. A reviewer who doesn't recheck the algebra has no way to tell the calculation is wrong from the output alone. Any time a tax, discount, or fee applies to a difference, the difference has to be parenthesised before the rate touches it.
You practiced parenthesising a subtraction so it completes before the percentage scaling. Without parentheses, 8000 - 3000 * 0.20 would tax only the cost (silently producing a wrong but plausible-looking number) — the recurring trap whenever a tax, discount, or fee is applied to a difference rather than a single value.
