Helix Systems' budget office receives the annual departmental allocation as the text string '10000' from an external data feed. The allocation must be expressed as a whole number before the system can divide it.
Write a query to return the equal quarterly share for one department.
Output:
- A single row with one column,
quarterly_budget.
Run previews · Check grades
Write a query, then run it to see results here.
Worked solution Try it yourself first
SELECT
'10000'::INTEGER / 4 AS quarterly_budgetThe shape
The ::integer cast converts the allocation string into a whole number, and dividing one integer by another integer keeps the result a whole number — exactly what the system needs for the quarterly share.
Clause by clause
'10000'::integercasts the text string the external feed delivered into the integer10000. The cast is positioned before the division so the operand the operator sees is already a number; the budget figure goes from characters to a typed integer in one step./ 4divides the cast result by the integer literal4. Both operands are integers, so PostgreSQL stays in integer arithmetic and returns the integer2500. With10000and4there's no remainder to worry about; the division is exact even without leaving the integer type.AS quarterly_budgetlabels the result as the business field the budget office is generating.
Why this and not '10000'::numeric / 4
The prompt is explicit: the allocation must be expressed as a whole number. Casting to numeric would return 2500.0000000000000000 — the same dollar amount, the wrong type. The system downstream expects integer cents-free quarterly shares, so the integer cast is the one the requirement calls for.
If the divisor weren't an exact factor, the choice would matter more sharply. '10001'::integer / 4 returns 2500; '10001'::numeric / 4 returns 2500.25. Picking the cast is picking which result you want.
The trap
Integer-divided-by-integer drops the fractional part silently. No error, no flag. If the allocation changes from $10,000 to $10,001, the integer-form query keeps returning 2500 and the missing $0.25 × 4 = $1.00 lands somewhere invisible. When whole numbers are the requirement, that's correct behavior; when precision is, casting one operand to numeric is what preserves it.
You practiced casting text to integer and then doing integer division. Integer-divide-by-integer drops the decimal — that's the surprise behavior whenever both operands are whole.
