Helix Systems' workforce planning analyst is working with a legacy system that stores headcounts as plain text strings rather than numbers. When 7 people are divided into 2 equal groups, both figures arrive from the source feed as the text strings '7' and '2'.
Write a query to return how many whole people end up per group.
Output:
- A single row with one column,
division_result, expressed as a whole number.
Run previews · Check grades
Write a query, then run it to see results here.
Worked solution Try it yourself first
SELECT
'7'::INTEGER / '2'::INTEGER AS division_resultThe shape
Both operands arrive as text from the legacy feed, so both need casts before the division operator can run. Casting both to integer keeps the division in integer arithmetic, which is what the prompt asks for — whole people per group, no half-people.
Clause by clause
'7'::integercasts the headcount string'7'to the integer7. The legacy system stored the value as text, so the cast is the bridge from characters to a number PostgreSQL can divide./ '2'::integerdoes the same for the divisor: the string'2'becomes the integer2, and the/operator now has two compatible operands to work with.- The division returns
3. Both operands are integers, so PostgreSQL stays in integer arithmetic and drops the fractional part.7 / 2in integer arithmetic is3with a remainder of1; PostgreSQL discards the remainder and the result is exactly3. AS division_resultlabels the output column as the per-group headcount the workforce-planning analyst is producing.
Why this and not '7'::numeric / '2'::numeric
The choice of cast determines the result type, and the result type determines the answer. Casting both sides to numeric would return 3.5000000000000000 — the precise mathematical quotient. Casting both to integer returns 3 — the count of whole people per group, with the leftover person allocated elsewhere by some downstream rule the query doesn't see.
The prompt is explicit: how many whole people end up per group. That's the integer-cast answer. If the question were "what's the precise average headcount per group," the numeric cast would be the right one. The casts aren't interchangeable shortcuts — they're decisions about what kind of number the analyst wants back.
Once either operand is numeric, integer division is off the table — the integer side promotes to match. The only way to keep integer truncation is for both sides to stay integer.
The trap
The nastier trap with two text operands is forgetting either cast and getting a operator does not exist: text / text error. PostgreSQL won't quietly cast strings on division. Both sides of the operator have to be numeric types — the same type, ideally, to keep the result predictable. Whenever both operands come from text sources, both need explicit casts, and the casts should match unless there's a specific reason for a mixed result type.
You practiced casting both operands of an arithmetic operation. The result type is determined by the operands — two integers stay integer, with truncation included.
