Brightlane's finance team is preparing two bonus figures for an audit trail. A $10,000 pool is divided equally among 3 staff members, and the report must show both:
- The whole-dollar amount each person receives under strict equal integer allocation.
- The exact decimal share, including fractional cents.
Write a query to return both values in a single row.
Output:
- A single row with two columns:
integer_share(whole dollars) andexact_share(decimal 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 / 3 AS integer_share,
10000::NUMERIC / 3 AS exact_shareThe shape
The same two numbers divided two different ways. The first expression keeps both operands as integers and truncates to a whole-dollar share; the second casts one operand to numeric and preserves the fractional cents. Two columns, side by side, make the contrast visible on a single row.
Clause by clause
10000 / 3 AS integer_sharedivides two integers. PostgreSQL applies integer division, the fractional part is dropped before the result lands, and the column returns3333. That's the whole-dollar amount each staff member receives under strict equal integer allocation — the figure the audit needs first.10000::numeric / 3 AS exact_sharecasts the left operand tonumericbefore the division. With one operand nownumeric, PostgreSQL promotes the other to match and computes in decimal arithmetic, returning3333.333.... The fractional cents survive into the result because the cast happens before the operator evaluates.- The comma between the two expressions is what puts both columns in the same row. Each expression sources from the same literals (
10000and3); the only difference between them is the cast on the left operand of the second.
Why this and not two separate queries
The audit report has to show both figures together. Running two queries and assembling the result afterward works, but it loses the side-by-side contrast that makes the report readable. Pairing the columns makes it obvious that the same arithmetic with different operand types produces different answers — 3333 versus 3333.333... — and that the difference is real, not a rounding artifact. The AS aliases also encode which figure is which directly into the column names, so the result survives into whatever spreadsheet or report it feeds into.
The trap
The two expressions look almost identical. The only difference is the ::numeric cast, and it sits at the very start of the second expression where a quick read might miss it. Drop the cast on exact_share and both columns return 3333 — the audit silently loses the fractional cents on the column that was supposed to preserve them. Cast presence is what separates the two calculations; once both operands are integers, the truncation is already done by the time anything downstream can react to it.
You practiced producing two values from the same numbers — one with integer division, one with decimal division — in a single query. The recurring lesson: identical operands plus different operand types yield different results, and naming both columns side by side is how an audit report makes that contrast visible.
