Bryan Green <[email protected]> writes:
> select_views runs "SELECT * FROM street" with no ORDER BY, and its iexit
> query, "SELECT name, #thepath", orders only by name and the point count.
> Both lean on heap scan order for the rest, so the expected output isn't
> deterministic and can shift with page layout or scan order.
> The fix gives each query a total ordering (COLLATE "C" so it's
> locale-independent). Since the ordering covers every output column, rows a
> scan could reorder are identical in the output anyway, so the result is
> stable.
I'm disinclined to accept this patch. You've shown no actual evidence
of output instability, and we have decades of experience showing the
contrary.
I'm not unsympathetic to the idea that this test could be a headache
for someone trying to run the regression tests atop a different table
AM --- but if we were trying to make the tests safe for scenarios
like that, there are hundreds of other places that would have to
change too. And the implications of doing that are not great.
As the manual explains:
You might wonder why we don't order all the regression test queries
explicitly
to get rid of this issue once and for all. The reason is that that would
make the regression tests less useful, not more, since they'd tend
to exercise query plan types that produce ordered results to the
exclusion of those that don't.
I suspect that in a fair number of places, we'd actually find
ourselves breaking the intent of the test case because it would
now not exercise the plan shape it was made to test. So moving
the goalposts meaningfully in this respect, while preserving
test coverage, seems like a pretty deep research project.
But short of that, I don't see much point in one-off fixes.
regards, tom lane
