Example:
create table foo(
id serial,
txt text
);
insert into foo(txt) values ('a'),('b'),('c') returning id;
Returns:
id
----
1
2
3
(3 rows)
It seems that the first id
in the return value will always be the id
for 'a'
, the second for 'b'
and so on, but is this defined behaviour of insert into
, or is it a coincidence that may fail under odd circumstances?
While the documentation isn't entirely clear, it does state that:
Now "similar to" isn't an ironclad guarantee, and I've raised this for discussion on the mailing list ... but in practice, PostgreSQL won't mess with the order of values in
RETURNING
. It's unlikely we'll ever be able to even if we want to for optimisation, because too many apps rely on it being ordered the same as the input.So... for
INSERT INTO ... VALUES (...), (...), ... RETURNING ...
and forINSERT INTO ... SELECT ... ORDER BY ... RETURNING ...
it should be safe to assume that the result relation is the in the same order as the input.While this won't help you now, 9.1 will include "writeable common table expressions". That's the official name for the
WITH
syntax. (Wikipedia.)This new ability should let you place your
INSERT ... RETURNING
inside aWITH
, give an alias, and thenSELECT
against that with a specific ordering with a plain oldORDER BY
clause.I don't see anything in the documentation that guarantees an order for
RETURNING
so I don't think you can depend on it. Odds are that theRETURNING
order will match theVALUES
order but I don't see any guarantees about what order theVALUES
will be inserted in either; theVALUES
are almost certainly going to be insert in order from left to right but again, there is no documented guarantee.Also, the relational model is set based so ordering is something applied by the user rather than an inherent property of a relation. In general, if there is no way to explicitly specify an ordering, there is no implied ordering.
Execute summary: the ordering you're seeing is probably what will always happen but it is not guaranteed so don't depend on it.