Adrian Maier wrote:
> On 20/07/06, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Reini Urban <rurban@x-ray.at> writes:
>> > BTW: HAVE_LONG_LONG_INT_64 is defined, so INT64_IS_BUSTED is
>> defined also.
>>
>> You sure? INT64_IS_BUSTED should *not* be set in that case --- it's
>> only supposed to be set if we couldn't find any 64-bit-int type at all.
>>
>> As for the regression test failure, it's odd because it looks to me that
>> the actual test output is an exact match to the default "float8.out"
>> file. I'm not sure why pg_regress chose to report a diff against
>> float8-small-is-zero.out instead. This may be another teething pain
>> of the new pg_regress-in-C code --- could you trace through it and see
>> what's happening?
>
> Apparently the regression test is comparing the results/float8.out
> with expected/float8-small-is-zero.out because of the following line
> in
> src/test/regress/resultmap :
> float8/i.86-pc-cygwin=float8-small-is-zero
>
> I've changed that line to :
> float8/i.86-pc-cygwin=float8
> and the regression test ended successfully : "All 100 tests passed."
>
> I don't know why there are several expected results for the float8 test,
> depending on the platform. Is the modification ok?
>
> I've attached the patch, and cc'ed to pgsql-patches.
>
The problem with this is that we have another Cygwin member on buildfarm
which passes the tests happily, and will thus presumably fail if we make
this patch. You are running Cygwin 1.5.21 and the other buildfarm member
is running 1.5.19, so that is possibly the difference.
Maybe we need to abandon trying to map float8 results exactly in the
resultmap file, and just let pg_regress pick the best fit as we do with
some other tests.
cheers
andrew
