> 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.
OK, I agree that the first option is probably preferable. But...
This will ripple across several of the regression tests, and we will
need to carefully check the changed results in those tests to ensure
that we understand the changes. We can't just assume that they are due
to the different input values.
Also, I would strongly prefer that we keep the internals of the float8
test the same, so it continues to test edge-effect operations and
results. Then, at or near the end of the float8 test, empty the table
and re-insert some better-behaved values (in fact, it could be the same
values that the table started with probably; I haven't looked).
- Tom
