The SQL RETURNING clause lets a DML statement (INSERT, UPDATE, DELETE) output data from the rows it just affected without requiring a separate SELECT. It is executed as part of the same transaction so the returned values reflect the final state of the modified rows. RETURNING can list one or more columns, expressions, or the wildcard *. You can alias returned columns, use computed expressions, and capture the result set in application code or a Common Table Expression (CTE).Benefits:- Saves a round-trip by combining write and read.- Guarantees consistency because the read happens inside the same statement lock scope.- Simplifies workflows like obtaining autogenerated primary keys, updated timestamps, or audit fields.Caveats:- Not all databases support it, or they implement it with different syntax (for example, SQL Server uses OUTPUT).- Large RETURNING result sets can increase network traffic.- Some ORMs enable it by default which may surprise users when performance degrades on bulk writes.
column_list
(required) - list of columns or expressions to return, or * for all columnsoutput_alias
(optional) - alias assigned to a returned column or expressionINSERT, UPDATE, DELETE, OUTPUT clause, RETURNING INTO, Common Table Expressions (CTE), INSERT ... SELECT
PostgreSQL 8.2 (2006)
PostgreSQL, SQLite (3.35+), MySQL (8.0.19+), Firebird, CockroachDB, and IBM Db2 support a RETURNING clause. Oracle provides RETURNING INTO and SQL Server offers the OUTPUT clause.
Yes. The clause returns one row for every row affected. If you insert five rows, you will receive five rows in the result set unless you add LIMIT or a condition.
Absolutely. It executes in the same transaction and lock scope as the DML statement, guaranteeing consistency.
You can fetch the result directly in your application code, assign it to a client variable, or wrap the DML in a CTE to reuse the output later in the same statement.