On Fri, Jan 31, 2014 at 2:28 AM, Michael Paquier
<michael.paqu...@gmail.com> wrote:
>> I took a look at this with a view to committing it but on examination
>> I'm not sure this is the best way to proceed.  The proposed text
>> documents that the tests should be run in a database called
>> regression, but the larger documentation chapter of which this section
>> is a part never explains how to run them anywhere else, so it feels a
>> bit like telling a ten-year-old not to burn out the clutch.
>>
>> The bit about not changing enable_* probably belongs, if anywhere, in
>> section 30.2, on test evaluation, rather than here.
> And what about the attached? I have moved all the content to 30.2, and
> added two paragraphs: one about the planner flags, the other about the
> database used.
> Regards,

Well, it doesn't really address my first concern, which was that you
talk about running the tests in a database named regression, but
that's exactly what "make check" does and it's unclear how you would
do anything else without modifying the source code.  It's not the
purpose of the documentation to tell you all the ways that you could
break things if you patch the tree.  I also don't want to document
exactly which tests would fail if you did hack things like that; that
documentation is likely to become outdated.

I think the remaining points you raise are worth mentioning.  I'm
attaching a patch with my proposed rewording of your changes.  I made
the section about configuration parameters a bit more generic and
adjusted the phrasing to sound more natural in English, and I moved
your mention of the other issues around a bit.  What do you think of
this version?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
diff --git a/doc/src/sgml/regress.sgml b/doc/src/sgml/regress.sgml
index 2b95587..edb476a 100644
--- a/doc/src/sgml/regress.sgml
+++ b/doc/src/sgml/regress.sgml
@@ -125,7 +125,9 @@ gmake installcheck-parallel
 </screen>
    The tests will expect to contact the server at the local host and the
    default port number, unless directed otherwise by <envar>PGHOST</envar> and
-   <envar>PGPORT</envar> environment variables.
+   <envar>PGPORT</envar> environment variables.  The tests will be run in a
+   database named <literal>regression</>; any existing database by this name
+   will be dropped.
   </para>
 
   <para>
@@ -147,7 +149,9 @@ gmake installcheck
 </screen>
    The <filename>contrib</> modules must have been built and installed first.
    You can also do this in a subdirectory of <filename>contrib</> to run
-   the tests for just one module.
+   the tests for just one module.  Tests of <literal>contrib</> modules will
+   be run in a database named <literal>contrib_regression</>; any existing
+   database by this name will be dropped.
   </para>
   </sect2>
 
@@ -471,6 +475,18 @@ diff results/random.out expected/random.out
      not worry unless the random test fails repeatedly.
     </para>
    </sect2>
+
+   <sect2>
+    <title>Configuration Parameters</title>
+
+    <para>
+     When running the tests against an existing installation, some non-default
+     parameter settings could cause the tests to fail.  For example, the
+     settings described in <xref linkend="runtime-config-query-enable">
+     could cause plan changes that would affect the results of tests which
+     use <command>EXPLAIN</>.
+    </para>
+   </sect2>
   </sect1>
 
 <!-- We might want to move the following section into the developer's guide. -->
-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to