VALUES(7)
π
VALUES(7) β the VALUES page, but make it make sense
ok so this is the VALUES page from the PostgreSQL 15.19 docs, and bestie, it's genuinely one of the most underrated little commands. let's get into it β¨
πΈ NAME
VALUES β compute a set of rows. that's it, that's the whole vibe. it makes rows π«Ά
π SYNOPSIS
VALUES ( expression [, ...] ) [, ...]
[ ORDER BY sort_expression [ ASC | DESC | USING operator ] [, ...] ]
[ LIMIT { count | ALL } ]
[ OFFSET start [ ROW | ROWS ] ]
[ FETCH { FIRST | NEXT } [ count ] { ROW | ROWS } ONLY ]
β¨ DESCRIPTION
so VALUES computes a row value, or a whole set of row values, all specified by value expressions. it's most commonly used to whip up a "constant table" inside a bigger command, but honestly it can absolutely stand on its own too πββοΈ
when you specify more than one row, all the rows must have the same number of elements β no cap, they gotta match. and the data types of the resulting table's columns? those get determined by combining the explicit or inferred types of the expressions appearing in that column, using the same rules as for UNION (peep Section 10.5 for that).
inside larger commands, VALUES is syntactically allowed anywhere that SELECT is. and because the grammar treats it like a SELECT, you can lowkey use the ORDER BY, LIMIT (or equivalently FETCH FIRST), and OFFSET clauses with a VALUES command. iconic behaviour honestly π
π PARAMETERS
expressionβ a constant or expression to compute and insert at the indicated place in the resulting table (set of rows). one special case: in aVALUESlist appearing at the top level of anINSERT, an expression can be replaced byDEFAULTto say "hey, insert the destination column's default value here". butDEFAULTcannot be used whenVALUESappears in other contexts. sorry bestie, that's the rule πsort_expressionβ an expression or integer constant indicating how to sort the result rows. it can refer to the columns of theVALUESresult ascolumn1,column2, etc. for more deets see ORDER BY Clause in theSELECT(7)documentation πoperatorβ a sorting operator. for details see ORDER BY Clause in theSELECT(7)documentation.countβ the maximum number of rows to return. for details see LIMIT Clause in theSELECT(7)documentation.startβ the number of rows to skip before starting to return rows. for details see LIMIT Clause in theSELECT(7)documentation.
π NOTES
ok real talk, listen to me: VALUES lists with very large numbers of rows should be avoided, because you might hit out-of-memory failures or just genuinely poor performance. not cute. π
but!! VALUES appearing within INSERT is a special case β because the desired column types are known from the INSERT's target table and don't need to be inferred by scanning the VALUES list β so it can handle larger lists than are practical in other contexts. so when it's the INSERT scenario, you're chilling π§
π¦ EXAMPLES
a bare VALUES command, no context, just vibes:
VALUES (1, 'one'), (2, 'two'), (3, 'three');
this returns a table of two columns and three rows. it's effectively equivalent to:
SELECT 1 AS column1, 'one' AS column2
UNION ALL
SELECT 2, 'two'
UNION ALL
SELECT 3, 'three';
more usually though, VALUES gets used inside a larger SQL command. the most common use is in INSERT:
INSERT INTO films (code, title, did, date_prod, kind)
VALUES ('T_601', 'Yojimbo', 106, '1961-06-16', 'Drama');
in the context of INSERT, entries of a VALUES list can be DEFAULT to indicate that the column default should be used here instead of specifying a value:
INSERT INTO films VALUES
('UA502', 'Bananas', 105, DEFAULT, 'Comedy', '82 minutes'),
('T_601', 'Yojimbo', 106, DEFAULT, 'Drama', DEFAULT);
VALUES can also be used where a sub-SELECT might be written β for example in a FROM clause:
SELECT f.*
FROM films f, (VALUES('MGM', 'Horror'), ('UA', 'Sci-Fi')) AS t (studio, kind)
WHERE f.studio = t.studio AND f.kind = t.kind;
UPDATE employees SET salary = salary * v.increase
FROM (VALUES(1, 200000, 1.2), (2, 400000, 1.4)) AS v (depno, target, increase)
WHERE employees.depno = v.depno AND employees.sales >= v.target;
note that an AS clause is required when VALUES is used in a FROM clause β just like it is for SELECT. it's not required that the AS clause specify names for all the columns, but it's good practice to do so. (the default column names for VALUES are column1, column2, etc. in PostgreSQL, but heads up β these names might be different in other database systems π)
when VALUES is used in INSERT, the values are all automatically coerced to the data type of the corresponding destination column. when it's used in other contexts, it might be necessary to specify the correct data type. and if the entries are all quoted literal constants, coercing the first one is sufficient to determine the assumed type for all of them:
SELECT * FROM machines
WHERE ip_address IN (VALUES('192.168.0.1'::inet), ('192.168.0.10'), ('192.168.1.43'));
Tip π β for simpleINtests, it's better to rely on the list-of-scalars form ofINthan to write aVALUESquery as shown above. the list of scalars method requires less writing and is often more efficient. take the shortcut bestie, it slays.
π COMPATIBILITY
VALUES conforms to the SQL standard. but LIMIT and OFFSET are PostgreSQL extensions β see also under SELECT(7) π«
π SEE ALSO
and that's the whole page fr fr π go build yourself a constant table, you absolute main character.
πΈ this has been the VALUES(7) page from PostgreSQL 15.19 Documentation, dated 2026 β mwah, go read SELECT(7) next, iykyk π«Ά
π¦ where this page comes from
- opensuse-leap 16.0: postgresql15 15.19-160000.1.1 Β· PostgreSQL
- opensuse-leap 16.0: postgresql15 15.19-160000.1.1 Β· PostgreSQL
- opensuse-leap 16.0: postgresql15 15.19-160000.1.1 Β· PostgreSQL
- opensuse-leap 16.0: postgresql15 15.19-160000.1.1 Β· PostgreSQL
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash-1017 on : a language model's rewrite of the original, under its terms