Helix Systems' finance director is finalizing the annual training budget of $50,000, which must be allocated equally across 7 departments. Each department's share must be calculated to full decimal precision — the amount cannot be rounded or truncated.
Write a query to return the exact per-department budget.
Output:
- A single row with one column,
per_department_budget, expressed as a decimal value.
Run previews · Check grades
Write a query, then run it to see results here.
Worked solution Try it yourself first
SELECT
50000::NUMERIC / 7 AS per_department_budgetThe shape
Casting one side of the division to numeric is what preserves the fractional part. Without the cast, dividing 50000 by 7 would drop everything past the decimal point and the finance director would lose precision the budget calculation depends on.
Clause by clause
50000::numericcasts the integer literal50000tonumeric. The training budget itself is a whole-dollar amount, but writing it as50000alone keeps it in integer arithmetic. The cast on the left of the/is what flips the whole expression's result type./ 7divides the cast value by the integer7. Once one operand isnumeric, PostgreSQL promotes the other tonumericto match, and the division runs at full decimal precision. The result is7142.857142857143— the repeating decimal carried out to PostgreSQL's default scale for an unsized numeric division.AS per_department_budgetlabels the output column. The finance director reads the result as a per-department allocation rather than an anonymous quotient.
Why this and not 50000 / 7
Without the cast, both operands are integers and PostgreSQL stays in integer arithmetic. 50000 / 7 returns 7142 — the .857142857143 is gone, and the seven departmental shares add up to 49994, not 50000. Six dollars vanish into the truncation. That's a rounding error in a budget reconciliation, and the prompt explicitly forbids it.
The cast can sit on either operand: 50000 / 7::numeric returns the same 7142.857142857143, as does 50000::numeric / 7::numeric and 50000.0 / 7. PostgreSQL only needs one side to be numeric to promote the whole expression. Pick whichever spelling reads cleanest in the surrounding query.
The trap
Integer division drops the decimal silently. There is no error, no warning, no flag in the result. 50000 / 7 runs, returns a number that looks like a per-department share, and the finance director reconciles against 49994 total instead of 50000. The missing six dollars surface later — in a variance report, an audit, or never. Any time the fractional part of a quotient is load-bearing, at least one operand must be a decimal type. The cast is the executable rule; forgetting it is the trap.
You practiced casting one operand to numeric to force decimal division. Whenever a quotient must keep its fractional part, the cast on either side flips the result type.
