Brightlane's warehouse operations analyst is planning load distribution across shipping crates ahead of a high-volume promotional week. There are 43 boxes to be split as evenly as possible across 8 crates, and the planning tool requires the exact decimal average — not a whole-number approximation.
Write a query to return the precise number of boxes per crate, including the fractional portion.
Output:
- A single row with one column,
boxes_per_crate, 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
43.0 / 8 AS boxes_per_crateThe shape
The decimal point on 43.0 is doing all the work. Without it, SQL treats both numbers as integers and drops the fractional part of the result entirely, which is exactly the whole-number approximation the planning tool can't use.
Clause by clause
SELECT 43.0 / 8evaluates the division once and returns its single result. There's noFROMbecause there's no table to read from; the values come straight from the prompt as literals.AS boxes_per_cratelabels the output column so the result reads as a domain quantity instead of a math expression. Without the alias, PostgreSQL would label the column?column?.
Why this and not 43 / 8
Which numbers carry a decimal point decides the type of the whole division. When both sides are integers, the result is also an integer. So 43 / 8 returns 5, and the .375 is gone before you ever see it. Writing one side with a decimal point makes that side a numeric, and SQL promotes the whole expression to numeric to match — which is why 43.0 / 8 returns 5.375000. The trailing zeroes are PostgreSQL's chosen scale for the result, not a rounding artifact.
Either side is enough. All three of these return the same value:
SELECT 43.0 / 8
SELECT 43 / 8.0
SELECT 43.0 / 8.0What does not work is writing the division as 43 / 8 and hoping the value can be salvaged after the fact. The truncation happens during the integer division itself, the moment the expression is evaluated. By the time the result exists, the .375 is already gone.
The trap
Divide two whole numbers and SQL silently drops the decimal. There is no error, no warning, no flag in the result. The query runs, returns a number that looks plausible, and the planning tool gets the wrong load per crate. Any time the fractional part of a quotient matters, put a decimal point on at least one of the operands before the division happens.
You practiced forcing decimal division by writing one operand with a decimal point (43.0 / 8). Integer-vs-decimal division is the recurring trap whenever a quotient must preserve its fractional part.
