A claims adjuster is preparing the payout calculation for a property insurance claim. The base value is confirmed at $5,000, but the adjustment multiplier has not yet been entered — it currently sits at NULL in the system.
Write a query to return what the calculation base * multiplier produces in its current state, in a single column named payout.
Output:
- A single row with one column,
payout. The single value in this row should reflect the result of multiplying5000byNULL.
Run previews · Check grades
Write a query, then run it to see results here.
Worked solution Try it yourself first
SELECT
5000 * NULL AS payoutThe shape
Any arithmetic involving NULL produces NULL. The missing multiplier propagates through the operator, and the calculation yields NULL rather than 0 or the base value alone.
Clause by clause
SELECT 5000 * NULLevaluates the multiplication, but with one operand missing the result is also missing. PostgreSQL has no rule that defaultsNULLto zero, no rule that treats it as the identity for multiplication, no rule that falls back to the other operand.NULLmeans "unknown," and any operation on an unknown value is itself unknown. The single value that comes back isNULL.AS payoutlabels the column as the calculation's output. The column appears in the result set with a single row whose value isNULL, which is the honest answer to the claim adjuster's question: the payout cannot be determined until the multiplier is entered.
Why this and not a fallback like zero
A reader coming from spreadsheet logic might expect 5000 * NULL to return 5000 or 0. SQL does neither. The propagation rule is consistent across every arithmetic operator: addition, subtraction, multiplication, and division with NULL all return NULL. Treating the missing multiplier as 1 or 0 would be a guess, and SQL does not guess. The claim system is showing the honest answer: the calculation is not ready because the multiplier has not been entered yet.
The trap
A NULL in one operand silently nullifies the entire result. There's no error, no warning, no row dropped from the output — just a single cell that comes back blank where a number was expected. The audit trail looks like "the calculation produced nothing," not "one input is missing." Any time an arithmetic expression sources from a nullable column, missing inputs have to be handled explicitly or the result will go quiet on the rows that need it most.
You practiced multiplying by NULL and watching the result propagate. The recurring rule: any arithmetic operation on a NULL operand returns NULL — a single missing input silently nullifies the entire calculated column, which is why production calculations almost always wrap nullable inputs in COALESCE.
