Tom,
> If the float8 data type works better, we should make a float8 table
> that is uniform across platforms in order to test the union code.
> There is really no point in including the boundary cases of float8
> into a test of union.
> Perhaps a better solution is to insert into the union.sql code a
> float8 table creation, fill it with well-behaved data, and then use
> that table in the union test.
Yes, this is the best solution. Would you like to take a crack at it? I
can consolidate a patch and patch results on my machine (which has been
the nominal "truth" machine for the last few releases).
I'm glad to do it. It seems like there are two approaches, here.
1. Modify the float8 test so that the table contains exactly the same
values on all platforms. In this case, this would mean removing
the "extra" rows that creep in on NetBSD because of the different
handling of small (in absolute value) numbers. Following this
strategy generally (i.e., in other similar cases) would mean that
all tables could be used at will by "derived" tests without
propagating special cases beyond the direct tests where boundary
cases are critical to include.
2. Add a new table with a subset of float8 values that are the same
on all platforms. This leaves the current float8 table the same,
but if this stategy is followed it will propagate special tables
for derived tests.
My preference is the first of these options, because it seems like a
better long-term strategy for developing new regression tests. If
platform-specific differences arise in whether or not values enter the
table, primary tests can be modified to remove extra ones so that the
tests always complete with a uniformly consistent set of values.
Unless there is some feeling that the second options is preferable, I
will proceed to fix the float8 table so that the values are the same
across platforms and adjust the expectations for float8 and union to
correspond.
Cheers,
Brook
