On Wed, Dec 14, 2016 at 9:37 PM, Stephen Frost <sfr...@snowman.net> wrote:
> * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: > > On 12/14/16 12:03 PM, Stephen Frost wrote: > > > If we do want to change that, perhaps we should also change psql to not > > > output the trailing whitespace in the first place..? > > > > Previous discussion: > > https://www.postgresql.org/message-id/flat/1285093687. > 5468.18.camel%40vanquo.pezone.net > > Thanks for that, but, frankly, it seems like most were in agreement that > we should go ahead and get rid of the trailing whitespace from psql's > output. The last couple emails on that thread hardly seems like a > critical issue (and I'm not sure why we couldn't eliminate that > whitespace and then programmatically forbid trailing whitespace > anyway..). > Thanks for the pointer, that's quite interesting. The real problem here, IMO, is the break in expected regression outputs. > The previous thread mainly discussed that in terms of its impact on > third-party tests using pg_regress, but for our own purposes it would be > just as nasty to need to adjust every single test case we back-patch for > the next five years. That's funny. Linked thread is from 2010. Here we are in 2016 arguing about it (we would've done by now). :) Looks like cost of having them around is not exactly 0. Either way, I've attached another version of my patch - this time it avoids touching example psql output. Baby steps. I'll let you decide on the way forward. I'm just happy to send some patches. Overall, regression tests that compare output of psql seems like a solution not without drawbacks. I absolutely see the appeal, but this practically freezes behavior of psql and makes e.g. server tests depend not only server behavior but also on piece of irrelevant client-only code. I could imagine a test system that is both has more-or-less human-readable expected.out files and does not depend on exact decorations added by psql. -- Vladimir Rusinov Storage SRE, Google Ireland Google Ireland Ltd.,Gordon House, Barrow Street, Dublin 4, Ireland Registered in Dublin, Ireland Registration Number: 368047
From 80cf7ee7f71c95c89e0908512e41154daff74d3a Mon Sep 17 00:00:00 2001
From: Vladimir Rusinov <vrusi...@google.com>
Date: Wed, 14 Dec 2016 22:19:08 +0000
Subject: [PATCH 1/1] Remove some of the trailing whitespaces from
documentation.
They are considered bad practice in many style guides and many editors
configured to strip them on every save.
Such editors will produce spurious diffs when editing the documentation.
Signed-off-by: Vladimir Rusinov <vrusi...@google.com>
---
doc/src/sgml/config.sgml | 2 +-
doc/src/sgml/parallel.sgml | 22 +++++++++++-----------
doc/src/sgml/ref/alter_table.sgml | 2 +-
doc/src/sgml/ref/insert.sgml | 2 +-
doc/src/sgml/ref/prepare.sgml | 2 +-
doc/src/sgml/ref/reindexdb.sgml | 2 +-
6 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index 0fc4e57..3b614b6 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -1181,7 +1181,7 @@ include_dir 'conf.d'
it in plaintext. <literal>on</> and <literal>off</> are also accepted, as
aliases for <literal>md5</> and <literal>plain</>, respectively.
</para>
-
+
</listitem>
</varlistentry>
diff --git a/doc/src/sgml/parallel.sgml b/doc/src/sgml/parallel.sgml
index cf4c1c9..bca4886 100644
--- a/doc/src/sgml/parallel.sgml
+++ b/doc/src/sgml/parallel.sgml
@@ -134,12 +134,12 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%';
<itemizedlist>
<listitem>
- <para>
+ <para>
The query writes any data or locks any database rows. If a query
contains a data-modifying operation either at the top level or within
a CTE, no parallel plans for that query will be generated. This is a
limitation of the current implementation which could be lifted in a
- future release.
+ future release.
</para>
</listitem>
@@ -153,7 +153,7 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%';
<literal>FOR x IN query LOOP .. END LOOP</literal> will never use a
parallel plan, because the parallel query system is unable to verify
that the code in the loop is safe to execute while parallel query is
- active.
+ active.
</para>
</listitem>
@@ -174,7 +174,7 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%';
query itself, that query will never use a parallel plan. This is a
limitation of the current implementation, but it may not be desirable
to remove this limitation, since it could result in a single query
- using a very large number of processes.
+ using a very large number of processes.
</para>
</listitem>
@@ -197,7 +197,7 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%';
<itemizedlist>
<listitem>
- <para>
+ <para>
No background workers can be obtained because of the limitation that
the total number of background workers cannot exceed
<xref linkend="guc-max-worker-processes">.
@@ -205,7 +205,7 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%';
</listitem>
<listitem>
- <para>
+ <para>
No background workers can be obtained because of the limitation that
the total number of background workers launched for purposes of
parallel query cannot exceed <xref linkend="guc-max-parallel-workers">.
@@ -213,7 +213,7 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%';
</listitem>
<listitem>
- <para>
+ <para>
The client sends an Execute message with a non-zero fetch count.
See the discussion of the
<link linkend="protocol-flow-ext-query">extended query protocol</link>.
@@ -228,7 +228,7 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%';
</listitem>
<listitem>
- <para>
+ <para>
A prepared statement is executed using a <literal>CREATE TABLE .. AS
EXECUTE ..</literal> statement. This construct converts what otherwise
would have been a read-only operation into a read-write operation,
@@ -237,7 +237,7 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%';
</listitem>
<listitem>
- <para>
+ <para>
The transaction isolation level is serializable. This situation
does not normally arise, because parallel query plans are not
generated when the transaction isolation level is serializable.
@@ -467,7 +467,7 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%';
transaction. If you write a function which does this, and this behavior
difference is important to you, mark such functions as
<literal>PARALLEL RESTRICTED</literal>
- to ensure that they execute only in the leader.
+ to ensure that they execute only in the leader.
</para>
<para>
@@ -475,7 +475,7 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%';
parallel-restricted functions or aggregates involved in the query in
order to obtain a superior plan. So, for example, if a <literal>WHERE</>
clause applied to a particular table is parallel restricted, the query
- planner will not consider placing the scan of that table below a
+ planner will not consider placing the scan of that table below a
<literal>Gather</> node. In some cases, it would be
possible (and perhaps even efficient) to include the scan of that table in
the parallel portion of the query and defer the evaluation of the
diff --git a/doc/src/sgml/ref/alter_table.sgml b/doc/src/sgml/ref/alter_table.sgml
index 333b01d..8ea6624 100644
--- a/doc/src/sgml/ref/alter_table.sgml
+++ b/doc/src/sgml/ref/alter_table.sgml
@@ -1121,7 +1121,7 @@ ALTER TABLE [ IF EXISTS ] <replaceable class="PARAMETER">name</replaceable>
Also, because selecting from the parent also selects from its descendents,
a constraint on the parent cannot be marked valid unless it is also marked
valid for those descendents. In all of these cases, <command>ALTER TABLE
- ONLY</command> will be rejected.
+ ONLY</command> will be rejected.
</para>
<para>
diff --git a/doc/src/sgml/ref/insert.sgml b/doc/src/sgml/ref/insert.sgml
index 00c984d..9339826 100644
--- a/doc/src/sgml/ref/insert.sgml
+++ b/doc/src/sgml/ref/insert.sgml
@@ -526,7 +526,7 @@ INSERT <replaceable>oid</replaceable> <replaceable class="parameter">count</repl
updated by the command.
</para>
</refsect1>
-
+
<refsect1>
<title>Notes</title>
diff --git a/doc/src/sgml/ref/prepare.sgml b/doc/src/sgml/ref/prepare.sgml
index 8efd51a..fea2196 100644
--- a/doc/src/sgml/ref/prepare.sgml
+++ b/doc/src/sgml/ref/prepare.sgml
@@ -73,7 +73,7 @@ PREPARE <replaceable class="PARAMETER">name</replaceable> [ ( <replaceable class
Prepared statements potentially have the largest performance advantage
when a single session is being used to execute a large number of similar
statements. The performance difference will be particularly
- significant if the statements are complex to plan or rewrite, e.g.
+ significant if the statements are complex to plan or rewrite, e.g.
if the query involves a join of many tables or requires
the application of several rules. If the statement is relatively simple
to plan and rewrite but relatively expensive to execute, the
diff --git a/doc/src/sgml/ref/reindexdb.sgml b/doc/src/sgml/ref/reindexdb.sgml
index 36df949..e4721d8 100644
--- a/doc/src/sgml/ref/reindexdb.sgml
+++ b/doc/src/sgml/ref/reindexdb.sgml
@@ -24,7 +24,7 @@ PostgreSQL documentation
<command>reindexdb</command>
<arg rep="repeat"><replaceable>connection-option</replaceable></arg>
<arg rep="repeat"><replaceable>option</replaceable></arg>
-
+
<arg choice="plain" rep="repeat">
<arg choice="opt">
<group choice="plain">
--
2.8.0.rc3.226.g39d4020
smime.p7s
Description: S/MIME Cryptographic Signature
