Brightlane's warehouse label-printing pipeline requires all product identifiers in text form so they can be embedded in barcode strings alongside other text. The product code 42 needs to be returned as a text value.
Write a query to convert it.
Output:
- A single row with one column,
product_code, typed as text.
Run previews · Check grades
Write a query, then run it to see results here.
Worked solution Try it yourself first
SELECT
42::TEXT AS product_code The shape
The ::text cast turns the integer 42 into the string '42' so the label-printing pipeline can stitch it together with other text. Casts run in both directions; this one goes number to string.
Clause by clause
SELECT 42::textreads the integer literal42and casts it totext. PostgreSQL renders the number as its string form — the digits4and2as characters — and hands the value back as text. The integer-to-text direction is the natural one for any pipeline that has to concatenate or embed a numeric identifier inside a longer string.AS product_codelabels the output column. Without the alias, PostgreSQL would call the columntext, which exposes the implementation type instead of the business field the warehouse system reads as the identifier.
The trap
The trap with the number-to-text direction is forgetting that string concatenation in PostgreSQL is strict about types. 'SKU-' || 42 raises an error because || doesn't implicitly cast an integer to text the way some other databases do. The fix is the same cast that's already here: 'SKU-' || 42::text produces the string 'SKU-42'. Any time a numeric ID needs to sit inside a longer label or barcode string, the cast to text is what makes the concatenation legal.
You practiced casting in the opposite direction — number to text. Casts go both ways, and integers becoming strings is the recurring shape anytime numeric IDs need to be embedded in text output.