Re: Abbreviated keys for Numeric - Mailing list pgsql-hackers

From Andrew Gierth
Subject Re: Abbreviated keys for Numeric
Date
Msg-id 87d23kv31b.fsf@news-spur.riddles.org.uk
Whole thread Raw
In response to Re: Abbreviated keys for Numeric  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
>>>>> "Tom" == Tom Lane <tgl@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.1AS 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
valuewhich ought to>> appear before 2 or 2.2 instead appears after it.  Strictly speaking,>> this is not the wrong
answerto the query, and could be perhaps>> explained by the planner choosing a hash aggregate rather than a sort>> +
uniqueplan.  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 sinceTom> none of the other critters are failing I
doubtthis 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)



pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: Providing catalog view to pg_hba.conf file - Patch submission
Next
From: Michael Paquier
Date:
Subject: Re: Compile warnings on OSX 10.10 clang 6.0