Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commit3bdadd0

Browse files
committed
Document tuple ordering differences as a possible cause of
regression test 'failures'.
1 parent1b8a219 commit3bdadd0

File tree

2 files changed

+60
-2
lines changed

2 files changed

+60
-2
lines changed

‎doc/src/sgml/regress.sgml

Lines changed: 35 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1,4 +1,4 @@
1-
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/regress.sgml,v 1.15 2000/12/22 18:57:50 petere Exp $ -->
1+
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/regress.sgml,v 1.16 2001/01/02 05:56:02 tgl Exp $ -->
22

33
<chapter id="regress">
44
<title id="regress-title">Regression Tests</title>
@@ -248,7 +248,40 @@ SELECT * from iexit;
248248
</programlisting>
249249
</para>
250250
</sect2>
251-
251+
252+
<sect2>
253+
<title>Tuple ordering differences</title>
254+
255+
<para>
256+
You might see differences in which the same tuples are output in a
257+
different order than what appears in the expected file. In most cases
258+
this is not, strictly speaking, a bug. Most of the regression test
259+
scripts are not so pedantic as to use an ORDER BY for every single
260+
SELECT, and so their result tuple orderings are not well-defined
261+
according to the letter of the SQL spec. In practice, since we are
262+
looking at the same queries being executed on the same data by the same
263+
software, we usually get the same result ordering on all platforms, and
264+
so the lack of ORDER BY isn't a problem. Some queries do exhibit
265+
cross-platform ordering differences, however.
266+
</para>
267+
268+
<para>
269+
Therefore, if you see an ordering difference, it's not something to
270+
worry about (unless the query does have an ORDER BY that your result
271+
is violating). But please report it anyway, so that we can add an
272+
ORDER BY to that particular query and thereby eliminate the bogus
273+
<quote>failure</quote> in future releases.
274+
</para>
275+
276+
<para>
277+
You might wonder why we don't ORDER all the regress test SELECTs to
278+
get rid of this issue once and for all. The reason is that that would
279+
make the regression tests less useful, not more, since they'd tend
280+
to exercise query plan types that produce ordered results to the
281+
exclusion of those that don't.
282+
</para>
283+
</sect2>
284+
252285
<sect2>
253286
<title>The <quote>random</quote> test</title>
254287

‎src/test/regress/README

Lines changed: 25 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -166,6 +166,31 @@ statements where these problems occur are the following:
166166
SELECT * from street;
167167
SELECT * from iexit;
168168

169+
Tuple ordering differences
170+
171+
You might see differences in which the same tuples are output in a
172+
different order than what appears in the expected file. In most cases
173+
this is not, strictly speaking, a bug. Most of the regression test
174+
scripts are not so pedantic as to use an ORDER BY for every single
175+
SELECT, and so their result tuple orderings are not well-defined
176+
according to the letter of the SQL spec. In practice, since we are
177+
looking at the same queries being executed on the same data by the same
178+
software, we usually get the same result ordering on all platforms, and
179+
so the lack of ORDER BY isn't a problem. Some queries do exhibit
180+
cross-platform ordering differences, however.
181+
182+
Therefore, if you see an ordering difference, it's not something to
183+
worry about (unless the query does have an ORDER BY that your result
184+
is violating). But please report it anyway, so that we can add an
185+
ORDER BY to that particular query and thereby eliminate the bogus
186+
"failure" in future releases.
187+
188+
You might wonder why we don't ORDER all the regress test SELECTs to
189+
get rid of this issue once and for all. The reason is that that would
190+
make the regression tests less useful, not more, since they'd tend
191+
to exercise query plan types that produce ordered results to the
192+
exclusion of those that don't.
193+
169194
The "random" test
170195

171196
There is at least one case in the "random" test script that is

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp