An external financial reporting system ingests data and requires a column named exactly NetProfit — capital N, capital P, no spaces or underscores. The figure is $9,500 in revenue minus $4,200 in costs.
Write a query that returns net profit in a column with that exact name.
Output:
- A single row with one column named exactly
NetProfit— the column header must preserve the capital letters.
Run previews · Check grades
Write a query, then run it to see results here.
Worked solution Try it yourself first
SELECT
9500 - 4200 AS "NetProfit" The shape
The double quotes around "NetProfit" are what keep the capital N and capital P intact. Without them, PostgreSQL silently folds the alias to netprofit, and the external reporting system rejects the column.
Clause by clause
SELECT 9500 - 4200evaluates the subtraction and returns5300— revenue minus costs. Both operands are integer literals, so the result is the integer5300.AS "NetProfit"labels the output column with the exact header the external system needs. The double quotes tell PostgreSQL to take the case literally: capital N, capital P, no folding. The query that produced5300now hands it over with the right header.
Why this and not AS NetProfit
AS NetProfit is a syntactically valid alias. PostgreSQL accepts it without complaint, runs the query, and returns the right number. The column header that comes back is netprofit — all lowercase. The capitals were dropped during parsing, not at the end; the unquoted identifier was lowercased before it ever became a column name.
The gap between what you wrote and what the database stored is silent. The query ran. The number is correct. The only thing wrong is the header, and the only place that surfaces is when the external reporting system tries to find a column called NetProfit and doesn't find one. Whenever a downstream consumer is case-sensitive, the alias has to be quoted at the source. Renaming the column in the export step is extra work; quoting at the source is one pair of characters.
The trap
The trap here is the silence. There's no error, no warning, no flag in the result. The query runs, returns the right number, and the column header looks fine when you scan the output in the editor — netprofit is recognisable enough that the lowercase doesn't jump out. The mismatch only surfaces downstream, often in another team's tooling, sometimes hours later. Any alias that needs to keep its case takes double quotes — every time, no exceptions. The rule is the fix; remembering to apply it is the discipline.
You practiced quoting an alias to preserve case. PostgreSQL silently lowercases unquoted identifiers — even when the alias is otherwise legal — so any time the downstream system is case-sensitive, double quotes are non-optional.