Return one row per unique city value

The shape

DISTINCT treats two NULL values as equal for the purpose of deduplication, even though NULL = NULL is unknown everywhere else in SQL. That's the entire reason this query works as a single statement. Hundreds of customers with no city on file collapse into one NULL row in the dropdown, alongside every real city.

Clause by clause

• SELECT DISTINCT city returns the unique city values from whatever rows FROM hands up. The deduplication runs across the full candidate set, and a NULL row collapses against any other NULL row the same way two London rows would collapse.
• FROM customers is the row source. Every customer contributes their city value — including the missing ones — to the candidate set. There's no filter; the dropdown wants the missing case represented, not removed.

Why this and not a two-statement approach

The natural-feeling instinct is to think of NULL handling as a separate concern: deduplicate the real cities, then add a row for the missing case. That instinct comes from how NULL equality usually works in SQL, where two NULLs are never equal to each other. If DISTINCT followed those rules, every NULL row would survive deduplication as its own distinct value, and the dropdown would contain hundreds of empty rows.

DISTINCT doesn't follow those rules. The SQL standard makes a deliberate exception for deduplication contexts: two NULLs are equal for the purpose of removing duplicates. So the single SELECT DISTINCT city FROM customers produces exactly the dropdown shape the address-validation system needs — one row per real city plus one row representing the missing case.