>>>>> "Tom" == Tom Lane <t...@sss.pgh.pa.us> writes:
>> For those following along at home, the failures are on these queries: >> SELECT 1.1 AS two UNION SELECT 2.2; >> SELECT 1.1 AS two UNION SELECT 2; >> SELECT 1 AS two UNION SELECT 2.2; >> SELECT 1.1 AS three UNION SELECT 2 UNION ALL SELECT 2; >> In each case, the expected result is with the values in ascending >> numerical order. In each case, the 1 or 1.1 value which ought to >> appear before 2 or 2.2 instead appears after it. Strictly speaking, >> this is not the wrong answer to the query, and could be perhaps >> explained by the planner choosing a hash aggregate rather than a sort >> + unique plan. But this patch doesn't change the planner at all, so >> the plan should be the same as it has always been. Tom> Yeah. We could add an EXPLAIN to make certain, perhaps, but since Tom> none of the other critters are failing I doubt this explanation. This failure in the union.sql test is exactly the one that happens if you build with --disable-float8-byval, for what that's worth. Does the windows build perhaps not define USE_FLOAT8_BYVAL? that would explain the breakage. -- Andrew (irc:RhodiumToad) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
