VALUES clause for inline data in PostgreSQL - Deep Dive

Overview - VALUES clause for inline data

What is it?

The VALUES clause in PostgreSQL lets you create a small table of data right inside your query. Instead of reading data from a stored table, you write rows of data directly in the query. This is useful for quick tests, combining fixed data with tables, or inserting multiple rows at once.

Why it matters

Without the VALUES clause, you would need to create temporary tables or rely on existing tables to test or combine data. This would slow down development and make simple tasks more complex. VALUES lets you quickly add or test data inline, saving time and effort.

Where it fits

Before learning VALUES, you should understand basic SQL SELECT queries and table structures. After mastering VALUES, you can explore more advanced topics like JOINs with inline data, CTEs (Common Table Expressions), and bulk INSERT operations.

Mental Model

Core Idea

VALUES creates a small, temporary table of rows directly inside your SQL query for quick and flexible data use.

Think of it like...

It's like writing a short list of ingredients on a sticky note instead of going to the pantry to get them each time you cook.

┌───────────────┐
│ VALUES Clause │
├───────────────┤
│ (1, 'Apple')  │
│ (2, 'Banana') │  ← Inline rows of data
│ (3, 'Cherry') │
└───────────────┘
  ↓
Temporary table with columns and rows
  ↓
Used in SELECT, INSERT, or JOIN operations

Build-Up - 6 Steps

1

Foundation

Basic syntax of VALUES clause

Concept: Learn how to write simple rows of data using VALUES.

The VALUES clause lets you write rows like this: VALUES (1, 'A'), (2, 'B'), (3, 'C'); Each pair of parentheses is a row, and inside are column values separated by commas.

Result

A temporary table with 3 rows and 2 columns is created.

Understanding the syntax is the first step to using VALUES as a quick data source.

2

Foundation

Selecting data from VALUES

Concept: Use VALUES as a table source in a SELECT query.

You can select from VALUES by giving it an alias and column names: SELECT * FROM (VALUES (1, 'A'), (2, 'B')) AS t(id, letter); This treats VALUES like a table named 't' with columns 'id' and 'letter'.

Result

Query returns two rows with columns id and letter: 1 | A 2 | B

Knowing how to name columns lets you use VALUES just like a real table.

3

Intermediate

Using VALUES with INSERT for bulk data

Concept: Insert multiple rows into a table using VALUES.

You can insert many rows at once: INSERT INTO fruits (id, name) VALUES (1, 'Apple'), (2, 'Banana'), (3, 'Cherry'); This adds three rows to the 'fruits' table in one command.

Result

The fruits table now contains the three new rows.

VALUES simplifies adding multiple rows, making data loading faster and cleaner.

4

Intermediate

Combining VALUES with JOIN operations

🤔Before reading on: do you think you can join inline VALUES data with existing tables? Commit to yes or no.

Concept: Join inline data from VALUES with real tables to enrich queries.

You can join VALUES data with tables: SELECT t.id, t.name, c.category FROM (VALUES (1, 'Apple'), (2, 'Banana')) AS t(id, name) JOIN categories c ON t.id = c.fruit_id; This matches inline data with categories from another table.

Result

Returns rows combining inline fruit data with their categories from the categories table.

Joining VALUES data with tables allows flexible, temporary data combinations without creating real tables.

5

Advanced

Using VALUES in Common Table Expressions (CTEs)

🤔Before reading on: do you think VALUES can be used inside CTEs like regular tables? Commit to yes or no.

Concept: Use VALUES inside WITH clauses to create named temporary datasets for complex queries.

WITH temp_data AS ( VALUES (1, 'X'), (2, 'Y') ) SELECT * FROM temp_data; This creates a named temporary table 'temp_data' from VALUES for use in the main query.

Result

Query returns the rows from the VALUES inside the CTE.

Embedding VALUES in CTEs helps organize inline data for multi-step queries.

6

Expert

Performance and type inference nuances of VALUES

🤔Before reading on: do you think PostgreSQL always infers the correct data types for VALUES columns automatically? Commit to yes or no.

Concept: Understand how PostgreSQL infers data types in VALUES and how explicit casting affects performance and correctness.

PostgreSQL tries to guess the data type of each column in VALUES based on the first row. If types differ or are ambiguous, you may need to cast explicitly: VALUES (1::int, 'A'), (2, 'B'); Explicit casting avoids errors and can improve query planning.

Result

Queries run correctly with expected data types and better performance.

Knowing type inference behavior prevents subtle bugs and helps optimize queries using VALUES.

Under the Hood

VALUES creates an internal, temporary table structure during query execution. PostgreSQL parses the rows, infers or applies data types, and treats this as a virtual table accessible in the query. This temporary table exists only during query runtime and is not stored permanently.

Why designed this way?

VALUES was designed to allow quick, inline data without needing physical tables. This reduces overhead for small datasets and testing. The design balances flexibility with performance by inferring types but allowing explicit casts when needed.

┌───────────────┐
│ Query Parser  │
└──────┬────────┘
       │ Parses VALUES clause
┌──────▼────────┐
│ Type Inference│
│ & Casting    │
└──────┬────────┘
       │ Creates temporary table
┌──────▼────────┐
│ Query Planner │
│ & Executor   │
└──────┬────────┘
       │ Uses inline data as table
┌──────▼────────┐
│ Query Result  │
└───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does VALUES create a permanent table in the database? Commit to yes or no.

Common Belief: VALUES creates a real table stored in the database.

Reality: VALUES only creates a temporary, in-memory table for the duration of the query.

Why it matters: Thinking VALUES creates permanent tables can lead to confusion about data persistence and cleanup.

Quick: Can you use VALUES without aliasing columns? Commit to yes or no.

Common Belief: You can always select from VALUES without naming columns.

Reality: When selecting from VALUES, you must provide an alias with column names to reference the data properly.

Why it matters: Not aliasing columns causes syntax errors and blocks using VALUES in SELECT queries.

Quick: Does PostgreSQL always infer the correct data types for mixed VALUES rows? Commit to yes or no.

Common Belief: PostgreSQL automatically infers correct types for all VALUES rows without issues.

Reality: PostgreSQL infers types from the first row and may require explicit casts if types differ or are ambiguous.

Why it matters: Ignoring type inference can cause runtime errors or unexpected behavior in queries.

Quick: Is VALUES only useful for inserting data? Commit to yes or no.

Common Belief: VALUES is only for bulk inserting rows into tables.

Reality: VALUES is also useful for inline data selection, joining with tables, and creating temporary datasets in queries.

Why it matters: Limiting VALUES to inserts misses its power for flexible query building and testing.

Expert Zone

1

VALUES can be combined with LATERAL joins to generate dynamic row sets based on other table data.

2

Explicit type casting in VALUES improves query planning and avoids costly runtime type resolution.

3

Using VALUES inside CTEs can improve readability and modularize complex queries without creating temporary tables.

When NOT to use

VALUES is not suitable for large datasets or persistent storage. For large data, use temporary tables or real tables. For persistent data, use INSERT into permanent tables. VALUES is best for small, inline, or test data.

Production Patterns

In production, VALUES is often used for seeding lookup data, testing queries with fixed inputs, or combining small static datasets with live tables in reporting queries.

Connections

Common Table Expressions (CTEs)

VALUES can be used inside CTEs to create named temporary datasets.

Knowing VALUES inside CTEs helps build modular and readable queries with inline data.

Bulk INSERT operations

VALUES is the core syntax for inserting multiple rows efficiently.

Understanding VALUES clarifies how bulk inserts work and how to optimize data loading.

Spreadsheet cell ranges

Both represent small, fixed sets of data used temporarily for calculations.

Recognizing VALUES as a temporary data range helps relate SQL inline data to familiar spreadsheet concepts.

Common Pitfalls

#1 Trying to select from VALUES without aliasing columns.

Wrong approach:

SELECT * FROM VALUES (1, 'A'), (2, 'B');

Correct approach:

SELECT * FROM (VALUES (1, 'A'), (2, 'B')) AS t(id, letter);

Root cause:

PostgreSQL requires an alias with column names to treat VALUES as a table source.

#2 Mixing data types in VALUES without explicit casting.

Wrong approach:

VALUES (1, 'A'), ('two', 'B');

Correct approach:

VALUES (1::text, 'A'), ('two', 'B');

Root cause:

PostgreSQL infers types from the first row; mismatched types cause errors unless cast explicitly.

#3 Using VALUES for large datasets expecting good performance.

Wrong approach:

INSERT INTO big_table SELECT * FROM (VALUES (1, 'A'), (2, 'B'), ..., (1000000, 'Z')) AS t(id, val);

Correct approach:

Use COPY command or bulk load from files for large datasets instead of VALUES.

Root cause:

VALUES is designed for small inline data; large data causes memory and performance issues.

Key Takeaways

VALUES lets you write small tables of data directly inside SQL queries for quick use.

You must alias VALUES with column names to use it in SELECT statements.

VALUES is great for inserting multiple rows, testing, and joining inline data with tables.

PostgreSQL infers data types in VALUES but explicit casting avoids errors and improves performance.

VALUES is temporary and not meant for large or persistent data storage.