gmb wrote
>>> The best, which you won't
>>> like, is to wait for 9.4 where unnest() will most likely have a WITH
>>> ORDINALITY option and you can sort on that.
>
> The fact that this type of thing is on the 9.4 roadmap indicates (to me,
> in any case) that there are problems with the UNNEST functionality in the
> current version (I'm running 9.2).
>
> Thanks Vik, I'll take a look at the implementation you suggested.
To recap:
unnest() returns its output in the same order as the input. Since an array
is ordered it will be returned in the same output order by unnest. However,
since unnest() only returns a single column (though possibly of a composite
type) it cannot provide the row number in the output thus in order to
maintain the same order elsewhere in the query it is necessary to use
"ROW_NUMBER() OVER (...)" on the output of the unnest() - and before joining
it with any other unnest calls or tables - before supplying it to the rest
of the query. The "WITH ORDINALITY" functionality proposed for 9.4 will
cause the unnest() [and other] function to output this additional column
along with the usual output. This is, I am pretty such, a usability
enhancement that makes easier something that can be done today using
CTE/WITH and/or sub-queries.
David J.
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/UNNEST-result-order-vs-Array-data-tp5760087p5760126.html
Sent from the PostgreSQL - sql mailing list archive at Nabble.com.
