Brightlane's customer data normalization pipeline standardizes product names to uppercase for case-insensitive matching.
Write a query to return the uppercase version of the string 'Wireless Keyboard'.
Output:
- A single row with one column,
normalized_name, containing the uppercased string.
Schema · ecommerce 5 tables
Run previews · Check grades
Write a query, then run it to see results here.
Worked solution Try it yourself first
SELECT
UPPER('Wireless Keyboard') AS normalized_nameThe shape
UPPER('Wireless Keyboard') returns every character of the literal in its uppercase form, so the catalog pipeline gets the canonical key it uses for case-insensitive matching against the rest of the product list.
Clause by clause
SELECT UPPER('Wireless Keyboard') AS normalized_nameruns the function once against the literal string and labels the single result columnnormalized_name.UPPERwalks the input character by character and rewrites each letter to its uppercase equivalent; non-letter characters like the space pass through unchanged. The output is the one-row, one-column resultWIRELESS KEYBOARD.- There is no
FROMbecause there is no table to read from. The literal lives inside theSELECTitself, andUPPERreturns a single value for that single input.
Why this and not LOWER
LOWER does the same kind of work but in the opposite direction, and which one to use is a downstream decision. The pipeline here was built to match against an already-uppercased product list, so UPPER is the one that produces a value the rest of the system can join against. The rule that matters is that both sides of a case-insensitive comparison have to be normalized the same way; UPPER and LOWER are interchangeable in principle but not in any specific pipeline.
You practiced UPPER(...) — convert every character in a string to its uppercase equivalent, the standard way to normalize text for case-insensitive comparison.
