Greg Stark wrote:
UNION ALL should still preserve the order of the subqueries. It just
returns all the rows of each subquery one after the other with no
other work.
Although without an ORDER BY that's not well-defined and thus not
guaranteed to work in future versions either. I doubt we're
Ian Barwick wrote:
Note I'm not sure whether this is a bug, or whether the assumption
made for the original query (that the row order returned by the
subquery would be carried over to the main part of the query) is
incorrect but just happened to work as expected pre-8.4.
The latter. Without an
Ian Barwick wrote:
Workaround / solution to produce consistent results is to move the
ORDER BY 1 to the main SELECT clause:
SELECT 1 AS id , 2 AS tmpl_id
WHERE FALSE
UNION
SELECT * FROM
(SELECT 2 AS id, 96 AS tmpl_id
UNION
SELECT 3 AS id, 101 AS
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Ian Barwick wrote:
Note I'm not sure whether this is a bug, or whether the assumption
made for the original query (that the row order returned by the
subquery would be carried over to the main part of the query) is
incorrect but
On 18 Apr 2009, at 22:22, Tom Lane wrote:
This is mentioned in the release notes, but I suppose we'd better
promote it to the observe the following incompatibilities list...
This is a really funny one, because people naturally expect UNION
[ALL] to stay in the same order. Unlike the
On Sat, Apr 18, 2009 at 11:19 PM, Grzegorz Jaskiewicz
g...@pointblue.com.pl wrote:
This is a really funny one, because people naturally expect UNION [ALL] to
stay in the same order. Unlike the table, order here cannot change by
inserts/updates, etc.
I am sure many, even well experienced will
2009/4/19 Tom Lane t...@sss.pgh.pa.us
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Ian Barwick wrote:
Note I'm not sure whether this is a bug, or whether the assumption
made for the original query (that the row order returned by the
subquery would be carried over to the
