mirror/postgresql
2
0
Fork 0
mirror of https://git.postgresql.org/git/postgresql.git synced 2025-01-18 18:44:06 +08:00
Code Issues Packages Projects Releases Wiki Activity

Document tuple ordering differences as a possible cause of

Browse Source 
regression test 'failures'.
This commit is contained in:
Tom Lane 2001-01-02 05:56:02 +00:00
parent 1b8a219eef
commit 3bdadd0426
2 changed files with 60 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

37
doc/src/sgml/regress.sgml
View File

@ -1,4 +1,4 @@
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/regress.sgml,v 1.15 2000/12/22 18:57:50 petere Exp $ -->
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/regress.sgml,v 1.16 2001/01/02 05:56:02 tgl Exp $ -->
<chapter id="regress">
<title id="regress-title">Regression Tests</title>
@ -248,7 +248,40 @@ SELECT * from iexit;
</programlisting>
</para>
</sect2>
<sect2>
<title>Tuple ordering differences</title>
<para>
You might see differences in which the same tuples are output in a
different order than what appears in the expected file. In most cases
this is not, strictly speaking, a bug. Most of the regression test
scripts are not so pedantic as to use an ORDER BY for every single
SELECT, and so their result tuple orderings are not well-defined
according to the letter of the SQL spec. In practice, since we are
looking at the same queries being executed on the same data by the same
software, we usually get the same result ordering on all platforms, and
so the lack of ORDER BY isn't a problem. Some queries do exhibit
cross-platform ordering differences, however.
</para>
<para>
Therefore, if you see an ordering difference, it's not something to
worry about (unless the query does have an ORDER BY that your result
is violating). But please report it anyway, so that we can add an
ORDER BY to that particular query and thereby eliminate the bogus
<quote>failure</quote> in future releases.
</para>
<para>
You might wonder why we don't ORDER all the regress test SELECTs 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.
</para>
</sect2>
<sect2>
<title>The <quote>random</quote> test</title>

25
src/test/regress/README
View File

@ -166,6 +166,31 @@ statements where these problems occur are the following:
SELECT * from street;
SELECT * from iexit;
Tuple ordering differences
You might see differences in which the same tuples are output in a
different order than what appears in the expected file. In most cases
this is not, strictly speaking, a bug. Most of the regression test
scripts are not so pedantic as to use an ORDER BY for every single
SELECT, and so their result tuple orderings are not well-defined
according to the letter of the SQL spec. In practice, since we are
looking at the same queries being executed on the same data by the same
software, we usually get the same result ordering on all platforms, and
so the lack of ORDER BY isn't a problem. Some queries do exhibit
cross-platform ordering differences, however.
Therefore, if you see an ordering difference, it's not something to
worry about (unless the query does have an ORDER BY that your result
is violating). But please report it anyway, so that we can add an
ORDER BY to that particular query and thereby eliminate the bogus
"failure" in future releases.
You might wonder why we don't ORDER all the regress test SELECTs 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.
The "random" test
There is at least one case in the "random" test script that is