Helix Systems' HR team is distributing a $10,000 bonus pool equally among 3 employees and needs the exact payout figure — including fractional cents — for the compensation letters.
Write a query to return each employee's precise share in a single column named exact_share.
Output:
- A single row with one column,
exact_share, expressed as a decimal value with full precision.
Run previews · Check grades
Write a query, then run it to see results here.
Worked solution Try it yourself first
SELECT
10000::NUMERIC / 3 AS exact_shareThe shape
The ::numeric cast on 10000 turns the left operand into a decimal value, and SQL promotes the whole division to numeric to match. The fractional cents that integer division would have silently dropped survive into the result.
Clause by clause
SELECT 10000::numeric / 3casts the integer10000tonumericfirst, then divides by3. Because one operand is nownumeric, PostgreSQL promotes the other operand and computes the division in decimal arithmetic. The result is3333.333..., the exact share each employee receives. Cast presence is what unlocks the fractional cents the compensation letters require.AS exact_sharelabels the column in the language the HR team is writing the letters in. The result reads as a precise payout figure rather than a math expression.
Why this and not 10000 / 3
Without the cast, both operands are integers, so PostgreSQL applies integer division and returns 3333. The .333... is gone the moment the operator evaluates — there's no rounding step that could be reversed, no decimal flag in the result. The query runs, returns a plausible whole-dollar figure, and the compensation letters go out short.
The cast can sit on either operand. All three of these return the same value:
SELECT 10000::numeric / 3
SELECT 10000 / 3::numeric
SELECT CAST(10000 AS numeric) / 3What does not work is wrapping the whole expression in a cast after the fact, as in (10000 / 3)::numeric. The integer division has already happened inside the parentheses and the fractional part is gone before the cast runs.
The trap
Two integer operands and a division operator combine to silently truncate. There's no warning, no error, no flag in the result — just a plausible-looking whole number that quietly omits the cents. Any time a quotient needs to preserve its fractional part, one of the operands has to be numeric before the division evaluates.
You practiced casting one operand to numeric to force decimal division. The recurring rule: when at least one operand is decimal, the result preserves its fractional part; when both are integer, PostgreSQL truncates silently.
