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. -- Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-sql
