[PATCH] Remove trailing whitespaces from documentation
They are considered bad practice in many style guides and many editors
configured to stip them on every save.
Such editors will produce spurious diffs when editing the documentation.
Therefore, I propose this patch.
--
Vladimir Rusinov
Storage SRE, Google Ireland
Google Ireland Ltd.,Gordon House, Barrow Street, Dublin 4, Ireland
Registered in Dublin, Ireland
Registration Number: 368047
Attachments:
0001-Remove-trailing-whitespaces-from-documentation.patchtext/x-patch; charset=US-ASCII; name=0001-Remove-trailing-whitespaces-from-documentation.patchDownload
From c1e5b6fa577c1af0934a3f0735b7860305ca7500 Mon Sep 17 00:00:00 2001
From: Vladimir Rusinov <vrusinov@google.com>
Date: Wed, 14 Dec 2016 16:34:59 +0000
Subject: [PATCH 1/1] Remove trailing whitespaces from documentation.
They are considered bad practice in many style guides and many editors
configured to stip them on every save.
Such editors will produce spurious diffs when editing the documentation.
Signed-off-by: Vladimir Rusinov <vrusinov@google.com>
---
doc/src/sgml/advanced.sgml | 8 +--
doc/src/sgml/charset.sgml | 12 ++--
doc/src/sgml/config.sgml | 2 +-
doc/src/sgml/datatype.sgml | 30 ++++-----
doc/src/sgml/dblink.sgml | 6 +-
doc/src/sgml/ddl.sgml | 6 +-
doc/src/sgml/func.sgml | 90 +++++++++++++--------------
doc/src/sgml/hstore.sgml | 8 +--
doc/src/sgml/json.sgml | 6 +-
doc/src/sgml/pageinspect.sgml | 14 ++---
doc/src/sgml/parallel.sgml | 24 ++++----
doc/src/sgml/pgfreespacemap.sgml | 4 +-
doc/src/sgml/plperl.sgml | 2 +-
doc/src/sgml/plpython.sgml | 4 +-
doc/src/sgml/ref/alter_table.sgml | 2 +-
doc/src/sgml/ref/create_index.sgml | 4 +-
doc/src/sgml/ref/explain.sgml | 4 +-
doc/src/sgml/ref/grant.sgml | 4 +-
doc/src/sgml/ref/insert.sgml | 2 +-
doc/src/sgml/ref/prepare.sgml | 2 +-
doc/src/sgml/ref/psql-ref.sgml | 14 ++---
doc/src/sgml/ref/reindexdb.sgml | 2 +-
doc/src/sgml/ref/rollback_to.sgml | 4 +-
doc/src/sgml/ref/select.sgml | 2 +-
doc/src/sgml/ref/set_role.sgml | 4 +-
doc/src/sgml/ref/set_session_auth.sgml | 4 +-
doc/src/sgml/ref/show.sgml | 2 +-
doc/src/sgml/rules.sgml | 8 +--
doc/src/sgml/sepgsql.sgml | 2 +-
doc/src/sgml/sql.sgml | 2 +-
doc/src/sgml/syntax.sgml | 14 ++---
doc/src/sgml/textsearch.sgml | 108 ++++++++++++++++-----------------
doc/src/sgml/xaggr.sgml | 4 +-
doc/src/sgml/xfunc.sgml | 14 ++---
34 files changed, 209 insertions(+), 209 deletions(-)
diff --git a/doc/src/sgml/advanced.sgml b/doc/src/sgml/advanced.sgml
index 1e45511..aab334d 100644
--- a/doc/src/sgml/advanced.sgml
+++ b/doc/src/sgml/advanced.sgml
@@ -344,7 +344,7 @@ SELECT depname, empno, salary, avg(salary) OVER (PARTITION BY depname) FROM emps
</programlisting>
<screen>
- depname | empno | salary | avg
+ depname | empno | salary | avg
-----------+-------+--------+-----------------------
develop | 11 | 5200 | 5020.0000000000000000
develop | 7 | 4200 | 5020.0000000000000000
@@ -395,7 +395,7 @@ FROM empsalary;
</programlisting>
<screen>
- depname | empno | salary | rank
+ depname | empno | salary | rank
-----------+-------+--------+------
develop | 8 | 6000 | 1
develop | 10 | 5200 | 2
@@ -459,7 +459,7 @@ SELECT salary, sum(salary) OVER () FROM empsalary;
</programlisting>
<screen>
- salary | sum
+ salary | sum
--------+-------
5200 | 47100
5000 | 47100
@@ -488,7 +488,7 @@ SELECT salary, sum(salary) OVER (ORDER BY salary) FROM empsalary;
</programlisting>
<screen>
- salary | sum
+ salary | sum
--------+-------
3500 | 3500
3900 | 7400
diff --git a/doc/src/sgml/charset.sgml b/doc/src/sgml/charset.sgml
index f8c7ac3..db5be56 100644
--- a/doc/src/sgml/charset.sgml
+++ b/doc/src/sgml/charset.sgml
@@ -1056,13 +1056,13 @@ CREATE DATABASE korean WITH ENCODING 'EUC_KR' LC_COLLATE='ko_KR.euckr' LC_CTYPE=
<screen>
$ <userinput>psql -l</userinput>
List of databases
- Name | Owner | Encoding | Collation | Ctype | Access Privileges
+ Name | Owner | Encoding | Collation | Ctype | Access Privileges
-----------+----------+-----------+-------------+-------------+-------------------------------------
- clocaledb | hlinnaka | SQL_ASCII | C | C |
- englishdb | hlinnaka | UTF8 | en_GB.UTF8 | en_GB.UTF8 |
- japanese | hlinnaka | UTF8 | ja_JP.UTF8 | ja_JP.UTF8 |
- korean | hlinnaka | EUC_KR | ko_KR.euckr | ko_KR.euckr |
- postgres | hlinnaka | UTF8 | fi_FI.UTF8 | fi_FI.UTF8 |
+ clocaledb | hlinnaka | SQL_ASCII | C | C |
+ englishdb | hlinnaka | UTF8 | en_GB.UTF8 | en_GB.UTF8 |
+ japanese | hlinnaka | UTF8 | ja_JP.UTF8 | ja_JP.UTF8 |
+ korean | hlinnaka | EUC_KR | ko_KR.euckr | ko_KR.euckr |
+ postgres | hlinnaka | UTF8 | fi_FI.UTF8 | fi_FI.UTF8 |
template0 | hlinnaka | UTF8 | fi_FI.UTF8 | fi_FI.UTF8 | {=c/hlinnaka,hlinnaka=CTc/hlinnaka}
template1 | hlinnaka | UTF8 | fi_FI.UTF8 | fi_FI.UTF8 | {=c/hlinnaka,hlinnaka=CTc/hlinnaka}
(7 rows)
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/datatype.sgml b/doc/src/sgml/datatype.sgml
index 67d0c34..5686932 100644
--- a/doc/src/sgml/datatype.sgml
+++ b/doc/src/sgml/datatype.sgml
@@ -2984,7 +2984,7 @@ CREATE TABLE person (
);
INSERT INTO person VALUES ('Moe', 'happy');
SELECT * FROM person WHERE current_mood = 'happy';
- name | current_mood
+ name | current_mood
------+--------------
Moe | happy
(1 row)
@@ -3005,14 +3005,14 @@ SELECT * FROM person WHERE current_mood = 'happy';
INSERT INTO person VALUES ('Larry', 'sad');
INSERT INTO person VALUES ('Curly', 'ok');
SELECT * FROM person WHERE current_mood > 'sad';
- name | current_mood
+ name | current_mood
-------+--------------
Moe | happy
Curly | ok
(2 rows)
SELECT * FROM person WHERE current_mood > 'sad' ORDER BY current_mood;
- name | current_mood
+ name | current_mood
-------+--------------
Curly | ok
Moe | happy
@@ -3021,7 +3021,7 @@ SELECT * FROM person WHERE current_mood > 'sad' ORDER BY current_mood;
SELECT name
FROM person
WHERE current_mood = (SELECT MIN(current_mood) FROM person);
- name
+ name
-------
Larry
(1 row)
@@ -3060,7 +3060,7 @@ ERROR: operator does not exist: mood = happiness
<programlisting>
SELECT person.name, holidays.num_weeks FROM person, holidays
WHERE person.current_mood::text = holidays.happiness::text;
- name | num_weeks
+ name | num_weeks
------+-----------
Moe | 4
(1 row)
@@ -3831,7 +3831,7 @@ SELECT 'a fat cat sat on a mat and ate a fat rat'::tsvector;
<programlisting>
SELECT $$the lexeme ' ' contains spaces$$::tsvector;
- tsvector
+ tsvector
-------------------------------------------
' ' 'contains' 'lexeme' 'spaces' 'the'
</programlisting>
@@ -3842,7 +3842,7 @@ SELECT $$the lexeme ' ' contains spaces$$::tsvector;
<programlisting>
SELECT $$the lexeme 'Joe''s' contains a quote$$::tsvector;
- tsvector
+ tsvector
------------------------------------------------
'Joe''s' 'a' 'contains' 'lexeme' 'quote' 'the'
</programlisting>
@@ -3872,7 +3872,7 @@ SELECT 'a:1 fat:2 cat:3 sat:4 on:5 a:6 mat:7 and:8 ate:9 a:10 fat:11 rat:12'::ts
<programlisting>
SELECT 'a:1A fat:2B,4C cat:5D'::tsvector;
- tsvector
+ tsvector
----------------------------
'a':1A 'cat':5 'fat':2B,4C
</programlisting>
@@ -3891,7 +3891,7 @@ SELECT 'a:1A fat:2B,4C cat:5D'::tsvector;
<programlisting>
SELECT 'The Fat Rats'::tsvector;
- tsvector
+ tsvector
--------------------
'Fat' 'Rats' 'The'
</programlisting>
@@ -3904,7 +3904,7 @@ SELECT 'The Fat Rats'::tsvector;
<programlisting>
SELECT to_tsvector('english', 'The Fat Rats');
- to_tsvector
+ to_tsvector
-----------------
'fat':2 'rat':3
</programlisting>
@@ -3946,17 +3946,17 @@ SELECT to_tsvector('english', 'The Fat Rats');
<programlisting>
SELECT 'fat & rat'::tsquery;
- tsquery
+ tsquery
---------------
'fat' & 'rat'
SELECT 'fat & (rat | cat)'::tsquery;
- tsquery
+ tsquery
---------------------------
'fat' & ( 'rat' | 'cat' )
SELECT 'fat & rat & ! cat'::tsquery;
- tsquery
+ tsquery
------------------------
'fat' & 'rat' & !'cat'
@@ -3988,7 +3988,7 @@ SELECT 'fat:ab & cat'::tsquery;
to specify prefix matching:
<programlisting>
SELECT 'super:*'::tsquery;
- tsquery
+ tsquery
-----------
'super':*
</programlisting>
@@ -4005,7 +4005,7 @@ SELECT 'super:*'::tsquery;
<programlisting>
SELECT to_tsquery('Fat:ab & Cats');
- to_tsquery
+ to_tsquery
------------------
'fat':AB & 'cat'
</programlisting>
diff --git a/doc/src/sgml/dblink.sgml b/doc/src/sgml/dblink.sgml
index f19c6b1..9b1a309 100644
--- a/doc/src/sgml/dblink.sgml
+++ b/doc/src/sgml/dblink.sgml
@@ -151,13 +151,13 @@ GRANT SELECT ON TABLE foo TO regress_dblink_user;
\set ORIGINAL_USER :USER
\c - regress_dblink_user
SELECT dblink_connect('myconn', 'fdtest');
- dblink_connect
+ dblink_connect
----------------
OK
(1 row)
SELECT * FROM dblink('myconn','SELECT * FROM foo') AS t(a int, b text, c text[]);
- a | b | c
+ a | b | c
----+---+---------------
0 | a | {a0,b0,c0}
1 | b | {a1,b1,c1}
@@ -1370,7 +1370,7 @@ dblink_get_notify(text connname) returns setof (notify_name text, be_pid int, ex
<screen>
SELECT dblink_exec('LISTEN virtual');
- dblink_exec
+ dblink_exec
-------------
LISTEN
(1 row)
diff --git a/doc/src/sgml/ddl.sgml b/doc/src/sgml/ddl.sgml
index 7e1bc0e..df542fd 100644
--- a/doc/src/sgml/ddl.sgml
+++ b/doc/src/sgml/ddl.sgml
@@ -1789,19 +1789,19 @@ CREATE POLICY admin_local_only ON passwd AS RESTRICTIVE TO admin
<programlisting>
=> SELECT current_user;
- current_user
+ current_user
--------------
admin
(1 row)
=> select inet_client_addr();
- inet_client_addr
+ inet_client_addr
------------------
127.0.0.1
(1 row)
=> SELECT current_user;
- current_user
+ current_user
--------------
admin
(1 row)
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 0f9c9bf..fbc6b40 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -4424,44 +4424,44 @@ SELECT col1, (SELECT regexp_matches(col2, '(bar)(beque)')) FROM tab;
<programlisting>
SELECT foo FROM regexp_split_to_table('the quick brown fox jumps over the lazy dog', E'\\s+') AS foo;
- foo
+ foo
-------
- the
- quick
- brown
- fox
- jumps
- over
- the
- lazy
- dog
+ the
+ quick
+ brown
+ fox
+ jumps
+ over
+ the
+ lazy
+ dog
(9 rows)
SELECT regexp_split_to_array('the quick brown fox jumps over the lazy dog', E'\\s+');
- regexp_split_to_array
+ regexp_split_to_array
-----------------------------------------------
{the,quick,brown,fox,jumps,over,the,lazy,dog}
(1 row)
SELECT foo FROM regexp_split_to_table('the quick brown fox', E'\\s*') AS foo;
- foo
+ foo
-----
- t
- h
- e
- q
- u
- i
- c
- k
- b
- r
- o
- w
- n
- f
- o
- x
+ t
+ h
+ e
+ q
+ u
+ i
+ c
+ k
+ b
+ r
+ o
+ w
+ n
+ f
+ o
+ x
(16 rows)
</programlisting>
</para>
@@ -10285,32 +10285,32 @@ SELECT xmlexists('//town[text() = ''Toronto'']' PASSING BY REF '<towns><town>Tor
<screen><![CDATA[
SET xmloption TO DOCUMENT;
SELECT xml_is_well_formed('<>');
- xml_is_well_formed
+ xml_is_well_formed
--------------------
f
(1 row)
SELECT xml_is_well_formed('<abc/>');
- xml_is_well_formed
+ xml_is_well_formed
--------------------
t
(1 row)
SET xmloption TO CONTENT;
SELECT xml_is_well_formed('abc');
- xml_is_well_formed
+ xml_is_well_formed
--------------------
t
(1 row)
SELECT xml_is_well_formed_document('<pg:foo xmlns:pg="http://postgresql.org/stuff">bar</pg:foo>');
- xml_is_well_formed_document
+ xml_is_well_formed_document
-----------------------------
t
(1 row)
SELECT xml_is_well_formed_document('<pg:foo xmlns:pg="http://postgresql.org/stuff">bar</my:foo>');
- xml_is_well_formed_document
+ xml_is_well_formed_document
-----------------------------
f
(1 row)
@@ -10373,7 +10373,7 @@ SELECT xml_is_well_formed_document('<pg:foo xmlns:pg="http://postgresql.org/stuf
SELECT xpath('/my:a/text()', '<my:a xmlns:my="http://example.com">test</my:a>',
ARRAY[ARRAY['my', 'http://example.com']]);
- xpath
+ xpath
--------
{test}
(1 row)
@@ -10416,7 +10416,7 @@ SELECT xpath('//mydefns:b/text()', '<a xmlns="http://example.com"><b>test</b></a
SELECT xpath_exists('/my:a/text()', '<my:a xmlns:my="http://example.com">test</my:a>',
ARRAY[ARRAY['my', 'http://example.com']]);
- xpath_exists
+ xpath_exists
--------------
t
(1 row)
@@ -15169,7 +15169,7 @@ SELECT * FROM generate_series(4,3);
(0 rows)
SELECT generate_series(1.1, 4, 1.3);
- generate_series
+ generate_series
-----------------
1.1
2.4
@@ -15187,7 +15187,7 @@ SELECT current_date + s.a AS dates FROM generate_series(0,14,7) AS s(a);
SELECT * FROM generate_series('2008-03-01 00:00'::timestamp,
'2008-03-04 12:00', '10 hours');
- generate_series
+ generate_series
---------------------
2008-03-01 00:00:00
2008-03-01 10:00:00
@@ -15250,7 +15250,7 @@ SELECT * FROM generate_series('2008-03-01 00:00'::timestamp,
<programlisting>
-- basic usage
SELECT generate_subscripts('{NULL,1,NULL,2}'::int[], 1) AS s;
- s
+ s
---
1
2
@@ -15261,7 +15261,7 @@ SELECT generate_subscripts('{NULL,1,NULL,2}'::int[], 1) AS s;
-- presenting an array, the subscript and the subscripted
-- value requires a subquery
SELECT * FROM arrays;
- a
+ a
--------------------
{-1,-2}
{100,200,300}
@@ -15287,7 +15287,7 @@ select $1[i][j]
$$ LANGUAGE sql IMMUTABLE;
CREATE FUNCTION
SELECT * FROM unnest2(ARRAY[[1,2],[3,4]]);
- unnest2
+ unnest2
---------
1
2
@@ -16917,13 +16917,13 @@ SELECT pg_type_is_visible('myschema.widget'::regtype);
<programlisting>
SELECT pg_typeof(33);
- pg_typeof
+ pg_typeof
-----------
integer
(1 row)
SELECT typlen FROM pg_type WHERE oid = pg_typeof(33);
- typlen
+ typlen
--------
4
(1 row)
@@ -16935,13 +16935,13 @@ SELECT typlen FROM pg_type WHERE oid = pg_typeof(33);
value that is passed to it. Example:
<programlisting>
SELECT collation for (description) FROM pg_description LIMIT 1;
- pg_collation_for
+ pg_collation_for
------------------
"default"
(1 row)
SELECT collation for ('foo' COLLATE "de_DE");
- pg_collation_for
+ pg_collation_for
------------------
"de_DE"
(1 row)
@@ -18162,7 +18162,7 @@ postgres=# select pg_start_backup('label_goes_here');
above functions. For example:
<programlisting>
postgres=# SELECT * FROM pg_xlogfile_name_offset(pg_stop_backup());
- file_name | file_offset
+ file_name | file_offset
--------------------------+-------------
00000001000000000000000D | 4039624
(1 row)
diff --git a/doc/src/sgml/hstore.sgml b/doc/src/sgml/hstore.sgml
index db5d440..cea3939 100644
--- a/doc/src/sgml/hstore.sgml
+++ b/doc/src/sgml/hstore.sgml
@@ -501,7 +501,7 @@ CREATE TABLE test (col1 integer, col2 text, col3 text);
INSERT INTO test VALUES (123, 'foo', 'bar');
SELECT hstore(t) FROM test AS t;
- hstore
+ hstore
---------------------------------------------
"col1"=>"123", "col2"=>"foo", "col3"=>"bar"
(1 row)
@@ -515,9 +515,9 @@ CREATE TABLE test (col1 integer, col2 text, col3 text);
SELECT * FROM populate_record(null::test,
'"col1"=>"456", "col2"=>"zzz"');
- col1 | col2 | col3
+ col1 | col2 | col3
------+------+------
- 456 | zzz |
+ 456 | zzz |
(1 row)
</programlisting>
</para>
@@ -529,7 +529,7 @@ CREATE TABLE test (col1 integer, col2 text, col3 text);
INSERT INTO test VALUES (123, 'foo', 'bar');
SELECT (r).* FROM (SELECT t #= '"col3"=>"baz"' AS r FROM test t) s;
- col1 | col2 | col3
+ col1 | col2 | col3
------+------+------
123 | foo | baz
(1 row)
diff --git a/doc/src/sgml/json.sgml b/doc/src/sgml/json.sgml
index 3cf78d6..78047cb 100644
--- a/doc/src/sgml/json.sgml
+++ b/doc/src/sgml/json.sgml
@@ -190,13 +190,13 @@ SELECT '{"foo": [true, "bar"], "tags": {"a": 1, "b": null}}'::json;
details such as whitespace. For example, note the differences here:
<programlisting>
SELECT '{"bar": "baz", "balance": 7.77, "active":false}'::json;
- json
+ json
-------------------------------------------------
{"bar": "baz", "balance": 7.77, "active":false}
(1 row)
SELECT '{"bar": "baz", "balance": 7.77, "active":false}'::jsonb;
- jsonb
+ jsonb
--------------------------------------------------
{"bar": "baz", "active": false, "balance": 7.77}
(1 row)
@@ -208,7 +208,7 @@ SELECT '{"bar": "baz", "balance": 7.77, "active":false}'::jsonb;
example:
<programlisting>
SELECT '{"reading": 1.230e-5}'::json, '{"reading": 1.230e-5}'::jsonb;
- json | jsonb
+ json | jsonb
-----------------------+-------------------------
{"reading": 1.230e-5} | {"reading": 0.00001230}
(1 row)
diff --git a/doc/src/sgml/pageinspect.sgml b/doc/src/sgml/pageinspect.sgml
index d12dbac..cb7ae8e4 100644
--- a/doc/src/sgml/pageinspect.sgml
+++ b/doc/src/sgml/pageinspect.sgml
@@ -312,7 +312,7 @@ test=# SELECT * FROM bt_page_items('pg_cast_oid_index', 1);
not a valid <acronym>BRIN</acronym> page. For example:
<screen>
test=# SELECT brin_page_type(get_raw_page('brinidx', 0));
- brin_page_type
+ brin_page_type
----------------
meta
</screen>
@@ -334,7 +334,7 @@ test=# SELECT brin_page_type(get_raw_page('brinidx', 0));
about a <acronym>BRIN</acronym> index metapage. For example:
<screen>
test=# SELECT * FROM brin_metapage_info(get_raw_page('brinidx', 0));
- magic | version | pagesperrange | lastrevmappage
+ magic | version | pagesperrange | lastrevmappage
------------+---------+---------------+----------------
0xA8109CFA | 1 | 4 | 2
</screen>
@@ -357,7 +357,7 @@ test=# SELECT * FROM brin_metapage_info(get_raw_page('brinidx', 0));
For example:
<screen>
test=# SELECT * FROM brin_revmap_data(get_raw_page('brinidx', 2)) LIMIT 5;
- pages
+ pages
---------
(6,137)
(6,138)
@@ -385,13 +385,13 @@ test=# SELECT * FROM brin_revmap_data(get_raw_page('brinidx', 2)) LIMIT 5;
test=# SELECT * FROM brin_page_items(get_raw_page('brinidx', 5),
'brinidx')
ORDER BY blknum, attnum LIMIT 6;
- itemoffset | blknum | attnum | allnulls | hasnulls | placeholder | value
+ itemoffset | blknum | attnum | allnulls | hasnulls | placeholder | value
------------+--------+--------+----------+----------+-------------+--------------
- 137 | 0 | 1 | t | f | f |
+ 137 | 0 | 1 | t | f | f |
137 | 0 | 2 | f | f | f | {1 .. 88}
- 138 | 4 | 1 | t | f | f |
+ 138 | 4 | 1 | t | f | f |
138 | 4 | 2 | f | f | f | {89 .. 176}
- 139 | 8 | 1 | t | f | f |
+ 139 | 8 | 1 | t | f | f |
139 | 8 | 2 | f | f | f | {177 .. 264}
</screen>
The returned columns correspond to the fields in the
diff --git a/doc/src/sgml/parallel.sgml b/doc/src/sgml/parallel.sgml
index cf4c1c9..f2080ab 100644
--- a/doc/src/sgml/parallel.sgml
+++ b/doc/src/sgml/parallel.sgml
@@ -32,7 +32,7 @@
<screen>
EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%';
- QUERY PLAN
+ QUERY PLAN
-------------------------------------------------------------------------------------
Gather (cost=1000.00..217018.43 rows=1 width=97)
Workers Planned: 2
@@ -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/pgfreespacemap.sgml b/doc/src/sgml/pgfreespacemap.sgml
index f2f99d5..41ac929 100644
--- a/doc/src/sgml/pgfreespacemap.sgml
+++ b/doc/src/sgml/pgfreespacemap.sgml
@@ -81,7 +81,7 @@
<screen>
postgres=# SELECT * FROM pg_freespace('foo');
- blkno | avail
+ blkno | avail
-------+-------
0 | 0
1 | 0
@@ -106,7 +106,7 @@ postgres=# SELECT * FROM pg_freespace('foo');
(20 rows)
postgres=# SELECT * FROM pg_freespace('foo', 7);
- pg_freespace
+ pg_freespace
--------------
1216
(1 row)
diff --git a/doc/src/sgml/plperl.sgml b/doc/src/sgml/plperl.sgml
index 9117769..f55e0ef 100644
--- a/doc/src/sgml/plperl.sgml
+++ b/doc/src/sgml/plperl.sgml
@@ -649,7 +649,7 @@ SELECT init_hosts_query();
SELECT query_hosts('192.168.1.0/30');
SELECT release_hosts_query();
- query_hosts
+ query_hosts
-----------------
(1,192.168.1.1)
(2,192.168.1.2)
diff --git a/doc/src/sgml/plpython.sgml b/doc/src/sgml/plpython.sgml
index 4639778..c931565 100644
--- a/doc/src/sgml/plpython.sgml
+++ b/doc/src/sgml/plpython.sgml
@@ -461,7 +461,7 @@ return [1, 2, 3, 4, 5]
$$ LANGUAGE plpythonu;
SELECT return_arr();
- return_arr
+ return_arr
-------------
{1,2,3,4,5}
(1 row)
@@ -480,7 +480,7 @@ $$ LANGUAGE plpythonu;
SELECT * FROM test_type_conversion_array_int4(ARRAY[[1,2,3],[4,5,6]]);
INFO: ([[1, 2, 3], [4, 5, 6]], <type 'list'>)
- test_type_conversion_array_int4
+ test_type_conversion_array_int4
---------------------------------
{{1,2,3},{4,5,6}}
(1 row)
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/create_index.sgml b/doc/src/sgml/ref/create_index.sgml
index fcb7a60..cbe470f 100644
--- a/doc/src/sgml/ref/create_index.sgml
+++ b/doc/src/sgml/ref/create_index.sgml
@@ -459,9 +459,9 @@ CREATE [ UNIQUE ] INDEX [ CONCURRENTLY ] [ [ IF NOT EXISTS ] <replaceable class=
<programlisting>
postgres=# \d tab
Table "public.tab"
- Column | Type | Collation | Nullable | Default
+ Column | Type | Collation | Nullable | Default
--------+---------+-----------+----------+---------
- col | integer | | |
+ col | integer | | |
Indexes:
"idx" btree (col) INVALID
</programlisting>
diff --git a/doc/src/sgml/ref/explain.sgml b/doc/src/sgml/ref/explain.sgml
index f14a58d..af5415a 100644
--- a/doc/src/sgml/ref/explain.sgml
+++ b/doc/src/sgml/ref/explain.sgml
@@ -350,7 +350,7 @@ EXPLAIN (FORMAT YAML) SELECT * FROM foo WHERE i='4';
Total Cost: 5.98 +
Plan Rows: 1 +
Plan Width: 4 +
- Index Cond: "(i = 4)"
+ Index Cond: "(i = 4)"
(1 row)
</programlisting>
@@ -397,7 +397,7 @@ PREPARE query(int, int) AS SELECT sum(bar) FROM test
EXPLAIN ANALYZE EXECUTE query(100, 200);
- QUERY PLAN
+ QUERY PLAN
------------------------------------------------------------------------------------------------------------------------
HashAggregate (cost=9.54..9.54 rows=1 width=8) (actual time=0.156..0.161 rows=11 loops=1)
Group Key: foo
diff --git a/doc/src/sgml/ref/grant.sgml b/doc/src/sgml/ref/grant.sgml
index cd8f3f5..fcaf095 100644
--- a/doc/src/sgml/ref/grant.sgml
+++ b/doc/src/sgml/ref/grant.sgml
@@ -512,11 +512,11 @@ GRANT <replaceable class="PARAMETER">role_name</replaceable> [, ...] TO <replace
<programlisting>
=> \dp mytable
Access privileges
- Schema | Name | Type | Access privileges | Column access privileges
+ Schema | Name | Type | Access privileges | Column access privileges
--------+---------+-------+-----------------------+--------------------------
public | mytable | table | miriam=arwdDxt/miriam | col1:
: =r/miriam : miriam_rw=rw/miriam
- : admin=arw/miriam
+ : admin=arw/miriam
(1 row)
</programlisting>
The entries shown by <command>\dp</command> are interpreted thus:
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/psql-ref.sgml b/doc/src/sgml/ref/psql-ref.sgml
index 9915731..390ad15 100644
--- a/doc/src/sgml/ref/psql-ref.sgml
+++ b/doc/src/sgml/ref/psql-ref.sgml
@@ -4086,7 +4086,7 @@ testdb=> <userinput>\d my_table</userinput>
Column | Type | Collation | Nullable | Default
--------+---------+-----------+----------+---------
first | integer | | not null | 0
- second | text | | |
+ second | text | | |
</programlisting>
Now we change the prompt to something more interesting:
<programlisting>
@@ -4173,7 +4173,7 @@ second | four
with the <command>\crosstabview</command> command:
<programlisting>
testdb=> <userinput>SELECT first, second, first > 2 AS gt2 FROM my_table;</userinput>
- first | second | gt2
+ first | second | gt2
-------+--------+-----
1 | one | f
2 | two | f
@@ -4182,11 +4182,11 @@ testdb=> <userinput>SELECT first, second, first > 2 AS gt2 FROM my_table;<
(4 rows)
testdb=> <userinput>\crosstabview first second</userinput>
- first | one | two | three | four
+ first | one | two | three | four
-------+-----+-----+-------+------
- 1 | f | | |
- 2 | | f | |
- 3 | | | t |
+ 1 | f | | |
+ 2 | | f | |
+ 3 | | | t |
4 | | | | t
(4 rows)
</programlisting>
@@ -4198,7 +4198,7 @@ testdb=> <userinput>SELECT t1.first as "A", t2.first+100 AS "B", t1.first*(t2
testdb(> <userinput>row_number() over(order by t2.first) AS ord</userinput>
testdb(> <userinput>FROM my_table t1 CROSS JOIN my_table t2 ORDER BY 1 DESC</userinput>
testdb(> <userinput>\crosstabview "A" "B" "AxB" ord</userinput>
- A | 101 | 102 | 103 | 104
+ A | 101 | 102 | 103 | 104
---+-----+-----+-----+-----
4 | 404 | 408 | 412 | 416
3 | 303 | 306 | 309 | 312
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">
diff --git a/doc/src/sgml/ref/rollback_to.sgml b/doc/src/sgml/ref/rollback_to.sgml
index 060f408..328d3e2 100644
--- a/doc/src/sgml/ref/rollback_to.sgml
+++ b/doc/src/sgml/ref/rollback_to.sgml
@@ -112,14 +112,14 @@ DECLARE foo CURSOR FOR SELECT 1 UNION SELECT 2;
SAVEPOINT foo;
FETCH 1 FROM foo;
- ?column?
+ ?column?
----------
1
ROLLBACK TO SAVEPOINT foo;
FETCH 1 FROM foo;
- ?column?
+ ?column?
----------
2
diff --git a/doc/src/sgml/ref/select.sgml b/doc/src/sgml/ref/select.sgml
index 211e4c3..47bca5d 100644
--- a/doc/src/sgml/ref/select.sgml
+++ b/doc/src/sgml/ref/select.sgml
@@ -1751,7 +1751,7 @@ SELECT * FROM t
UNION ALL
SELECT * FROM t
- x
+ x
--------------------
0.534150459803641
0.520092216785997
diff --git a/doc/src/sgml/ref/set_role.sgml b/doc/src/sgml/ref/set_role.sgml
index a97ceab..b5beb49 100644
--- a/doc/src/sgml/ref/set_role.sgml
+++ b/doc/src/sgml/ref/set_role.sgml
@@ -108,7 +108,7 @@ RESET ROLE
<programlisting>
SELECT SESSION_USER, CURRENT_USER;
- session_user | current_user
+ session_user | current_user
--------------+--------------
peter | peter
@@ -116,7 +116,7 @@ SET ROLE 'paul';
SELECT SESSION_USER, CURRENT_USER;
- session_user | current_user
+ session_user | current_user
--------------+--------------
peter | paul
</programlisting>
diff --git a/doc/src/sgml/ref/set_session_auth.sgml b/doc/src/sgml/ref/set_session_auth.sgml
index 96d279a..35d0f9f 100644
--- a/doc/src/sgml/ref/set_session_auth.sgml
+++ b/doc/src/sgml/ref/set_session_auth.sgml
@@ -80,7 +80,7 @@ RESET SESSION AUTHORIZATION
<programlisting>
SELECT SESSION_USER, CURRENT_USER;
- session_user | current_user
+ session_user | current_user
--------------+--------------
peter | peter
@@ -88,7 +88,7 @@ SET SESSION AUTHORIZATION 'paul';
SELECT SESSION_USER, CURRENT_USER;
- session_user | current_user
+ session_user | current_user
--------------+--------------
paul | paul
</programlisting>
diff --git a/doc/src/sgml/ref/show.sgml b/doc/src/sgml/ref/show.sgml
index 46bb239..8040d5b 100644
--- a/doc/src/sgml/ref/show.sgml
+++ b/doc/src/sgml/ref/show.sgml
@@ -167,7 +167,7 @@ SHOW geqo;
Show all settings:
<programlisting>
SHOW ALL;
- name | setting | description
+ name | setting | description
-------------------------+---------+-------------------------------------------------
allow_system_table_mods | off | Allows modifications of the structure of ...
.
diff --git a/doc/src/sgml/rules.sgml b/doc/src/sgml/rules.sgml
index ca1b767..1f76010 100644
--- a/doc/src/sgml/rules.sgml
+++ b/doc/src/sgml/rules.sgml
@@ -1024,7 +1024,7 @@ VACUUM ANALYZE wrd;
<programlisting>
SELECT count(*) FROM words WHERE word = 'caterpiler';
- count
+ count
-------
0
(1 row)
@@ -1060,7 +1060,7 @@ SELECT count(*) FROM words WHERE word = 'caterpiler';
<programlisting>
SELECT word FROM words ORDER BY word <-> 'caterpiler' LIMIT 10;
- word
+ word
---------------
cater
caterpillar
@@ -1350,7 +1350,7 @@ UPDATE shoelace_data SET sl_avail = 6 WHERE sl_name = 'sl7';
<programlisting>
SELECT * FROM shoelace_log;
- sl_name | sl_avail | log_who | log_when
+ sl_name | sl_avail | log_who | log_when
---------+----------+---------+----------------------------------
sl7 | 6 | Al | Tue Oct 20 16:14:45 1998 MET DST
(1 row)
@@ -1731,7 +1731,7 @@ SELECT * FROM shoelace ORDER BY sl_name;
SELECT * FROM shoelace_log;
- sl_name | sl_avail | log_who| log_when
+ sl_name | sl_avail | log_who| log_when
---------+----------+--------+----------------------------------
sl7 | 6 | Al | Tue Oct 20 19:14:45 1998 MET DST
sl3 | 10 | Al | Tue Oct 20 19:25:16 1998 MET DST
diff --git a/doc/src/sgml/sepgsql.sgml b/doc/src/sgml/sepgsql.sgml
index 6f80933..1cc15b2 100644
--- a/doc/src/sgml/sepgsql.sgml
+++ b/doc/src/sgml/sepgsql.sgml
@@ -602,7 +602,7 @@ regression=# select sepgsql_getcon();
(1 row)
regression=# SELECT sepgsql_setcon('unconfined_u:unconfined_r:unconfined_t:s0-s0:c1.c4');
- sepgsql_setcon
+ sepgsql_setcon
----------------
t
(1 row)
diff --git a/doc/src/sgml/sql.sgml b/doc/src/sgml/sql.sgml
index 57396d7..0cf33ca 100644
--- a/doc/src/sgml/sql.sgml
+++ b/doc/src/sgml/sql.sgml
@@ -1899,7 +1899,7 @@ SELECT * FROM London_Suppliers
<screen>
SNAME | PNAME
-------+-------
- Smith | Screw
+ Smith | Screw
</screen>
</para>
diff --git a/doc/src/sgml/syntax.sgml b/doc/src/sgml/syntax.sgml
index 000da39..f575924 100644
--- a/doc/src/sgml/syntax.sgml
+++ b/doc/src/sgml/syntax.sgml
@@ -2556,7 +2556,7 @@ LANGUAGE SQL IMMUTABLE STRICT;
to functions in <productname>PostgreSQL</productname>. An example is:
<screen>
SELECT concat_lower_or_upper('Hello', 'World', true);
- concat_lower_or_upper
+ concat_lower_or_upper
-----------------------
HELLO WORLD
(1 row)
@@ -2566,7 +2566,7 @@ SELECT concat_lower_or_upper('Hello', 'World', true);
Another example is:
<screen>
SELECT concat_lower_or_upper('Hello', 'World');
- concat_lower_or_upper
+ concat_lower_or_upper
-----------------------
hello world
(1 row)
@@ -2592,7 +2592,7 @@ SELECT concat_lower_or_upper('Hello', 'World');
For example:
<screen>
SELECT concat_lower_or_upper(a => 'Hello', b => 'World');
- concat_lower_or_upper
+ concat_lower_or_upper
-----------------------
hello world
(1 row)
@@ -2603,13 +2603,13 @@ SELECT concat_lower_or_upper(a => 'Hello', b => 'World');
order, for example:
<screen>
SELECT concat_lower_or_upper(a => 'Hello', b => 'World', uppercase => true);
- concat_lower_or_upper
+ concat_lower_or_upper
-----------------------
HELLO WORLD
(1 row)
SELECT concat_lower_or_upper(a => 'Hello', uppercase => true, b => 'World');
- concat_lower_or_upper
+ concat_lower_or_upper
-----------------------
HELLO WORLD
(1 row)
@@ -2620,7 +2620,7 @@ SELECT concat_lower_or_upper(a => 'Hello', uppercase => true, b => 'Wor
An older syntax based on ":=" is supported for backward compatibility:
<screen>
SELECT concat_lower_or_upper(a := 'Hello', uppercase := true, b := 'World');
- concat_lower_or_upper
+ concat_lower_or_upper
-----------------------
HELLO WORLD
(1 row)
@@ -2642,7 +2642,7 @@ SELECT concat_lower_or_upper(a := 'Hello', uppercase := true, b := 'World');
For example:
<screen>
SELECT concat_lower_or_upper('Hello', 'World', uppercase => true);
- concat_lower_or_upper
+ concat_lower_or_upper
-----------------------
HELLO WORLD
(1 row)
diff --git a/doc/src/sgml/textsearch.sgml b/doc/src/sgml/textsearch.sgml
index 2da7595..3e02523 100644
--- a/doc/src/sgml/textsearch.sgml
+++ b/doc/src/sgml/textsearch.sgml
@@ -275,7 +275,7 @@ SELECT 'fat & cow'::tsquery @@ 'a fat cat sat on a mat and ate a fat rat'::t
<programlisting>
SELECT to_tsvector('fat cats ate fat rats') @@ to_tsquery('fat & rat');
- ?column?
+ ?column?
----------
t
</programlisting>
@@ -284,7 +284,7 @@ SELECT to_tsvector('fat cats ate fat rats') @@ to_tsquery('fat & rat');
<programlisting>
SELECT 'fat cats ate fat rats'::tsvector @@ to_tsquery('fat & rat');
- ?column?
+ ?column?
----------
f
</programlisting>
@@ -333,12 +333,12 @@ text @@ text
<programlisting>
SELECT to_tsvector('fatal error') @@ to_tsquery('fatal <-> error');
- ?column?
+ ?column?
----------
t
SELECT to_tsvector('error is not fatal') @@ to_tsquery('fatal <-> error');
- ?column?
+ ?column?
----------
f
</programlisting>
@@ -355,12 +355,12 @@ SELECT to_tsvector('error is not fatal') @@ to_tsquery('fatal <-> error');
<programlisting>
SELECT phraseto_tsquery('cats ate rats');
- phraseto_tsquery
+ phraseto_tsquery
-------------------------------
'cat' <-> 'ate' <-> 'rat'
SELECT phraseto_tsquery('the cats ate the rats');
- phraseto_tsquery
+ phraseto_tsquery
-------------------------------
'cat' <-> 'ate' <2> 'rat'
</programlisting>
@@ -807,7 +807,7 @@ to_tsquery(<optional> <replaceable class="PARAMETER">config</replaceable> <type>
<screen>
SELECT to_tsquery('english', 'The & Fat & Rats');
- to_tsquery
+ to_tsquery
---------------
'fat' & 'rat'
</screen>
@@ -818,7 +818,7 @@ SELECT to_tsquery('english', 'The & Fat & Rats');
<screen>
SELECT to_tsquery('english', 'Fat | Rats:AB');
- to_tsquery
+ to_tsquery
------------------
'fat' | 'rat':AB
</screen>
@@ -827,7 +827,7 @@ SELECT to_tsquery('english', 'Fat | Rats:AB');
<screen>
SELECT to_tsquery('supern:*A & star:A*B');
- to_tsquery
+ to_tsquery
--------------------------
'supern':*A & 'star':*AB
</screen>
@@ -876,7 +876,7 @@ plainto_tsquery(<optional> <replaceable class="PARAMETER">config</replaceable> <
<screen>
SELECT plainto_tsquery('english', 'The Fat Rats');
- plainto_tsquery
+ plainto_tsquery
-----------------
'fat' & 'rat'
</screen>
@@ -887,7 +887,7 @@ SELECT plainto_tsquery('english', 'The Fat Rats');
<screen>
SELECT plainto_tsquery('english', 'The Fat & Rats:C');
- plainto_tsquery
+ plainto_tsquery
---------------------
'fat' & 'rat' & 'c'
</screen>
@@ -1266,7 +1266,7 @@ is to find all documents containing given query terms
and return them in order of their similarity to the
query.',
to_tsquery('query & similarity'));
- ts_headline
+ ts_headline
------------------------------------------------------------
containing given <b>query</b> terms
and return them in order of their <b>similarity</b> to the
@@ -1279,7 +1279,7 @@ and return them in order of their similarity to the
query.',
to_tsquery('query & similarity'),
'StartSel = <, StopSel = >');
- ts_headline
+ ts_headline
-------------------------------------------------------
containing given <query> terms
and return them in order of their <similarity> to the
@@ -1705,7 +1705,7 @@ CREATE TABLE aliases (t tsquery primary key, s tsquery);
INSERT INTO aliases VALUES(to_tsquery('supernovae'), to_tsquery('supernovae|sn'));
SELECT ts_rewrite(to_tsquery('supernovae & crab'), 'SELECT * FROM aliases');
- ts_rewrite
+ ts_rewrite
---------------------------------
'crab' & ( 'supernova' | 'sn' )
</screen>
@@ -1718,7 +1718,7 @@ SET s = to_tsquery('supernovae|sn & !nebulae')
WHERE t = to_tsquery('supernovae');
SELECT ts_rewrite(to_tsquery('supernovae & crab'), 'SELECT * FROM aliases');
- ts_rewrite
+ ts_rewrite
---------------------------------------------
'crab' & ( 'supernova' | 'sn' & !'nebula' )
</screen>
@@ -1785,12 +1785,12 @@ tsvector_update_trigger(tsv, 'pg_catalog.english', title, body);
INSERT INTO messages VALUES('title here', 'the body text is here');
SELECT * FROM messages;
- title | body | tsv
+ title | body | tsv
------------+-----------------------+----------------------------
title here | the body text is here | 'bodi':4 'text':5 'titl':1
SELECT title, body FROM messages WHERE tsv @@ to_tsquery('title & body');
- title | body
+ title | body
------------+-----------------------
title here | the body text is here
</screen>
@@ -2098,7 +2098,7 @@ LIMIT 10;
<screen>
SELECT alias, description, token FROM ts_debug('foo-bar-beta1');
- alias | description | token
+ alias | description | token
-----------------+------------------------------------------+---------------
numhword | Hyphenated word, letters and digits | foo-bar-beta1
hword_asciipart | Hyphenated word part, all ASCII | foo
@@ -2114,7 +2114,7 @@ SELECT alias, description, token FROM ts_debug('foo-bar-beta1');
<screen>
SELECT alias, description, token FROM ts_debug('http://example.com/stuff/index.html');
- alias | description | token
+ alias | description | token
----------+---------------+------------------------------
protocol | Protocol head | http://
url | URL | example.com/stuff/index.html
@@ -2438,7 +2438,7 @@ SELECT ts_lexize('public.simple_dict','The');
<screen>
SELECT * FROM ts_debug('english', 'Paris');
- alias | description | token | dictionaries | dictionary | lexemes
+ alias | description | token | dictionaries | dictionary | lexemes
-----------+-----------------+-------+----------------+--------------+---------
asciiword | Word, all ASCII | Paris | {english_stem} | english_stem | {pari}
@@ -2452,7 +2452,7 @@ ALTER TEXT SEARCH CONFIGURATION english
WITH my_synonym, english_stem;
SELECT * FROM ts_debug('english', 'Paris');
- alias | description | token | dictionaries | dictionary | lexemes
+ alias | description | token | dictionaries | dictionary | lexemes
-----------+-----------------+-------+---------------------------+------------+---------
asciiword | Word, all ASCII | Paris | {my_synonym,english_stem} | my_synonym | {paris}
</screen>
@@ -2521,7 +2521,7 @@ mydb=# SELECT to_tsquery('tst','indices');
(1 row)
mydb=# SELECT 'indexes are very useful'::tsvector;
- tsvector
+ tsvector
---------------------------------
'are' 'indexes' 'useful' 'very'
(1 row)
@@ -3222,31 +3222,31 @@ ts_debug(<optional> <replaceable class="PARAMETER">config</replaceable> <type>re
<screen>
SELECT * FROM ts_debug('english','a fat cat sat on a mat - it ate a fat rats');
- alias | description | token | dictionaries | dictionary | lexemes
+ alias | description | token | dictionaries | dictionary | lexemes
-----------+-----------------+-------+----------------+--------------+---------
asciiword | Word, all ASCII | a | {english_stem} | english_stem | {}
- blank | Space symbols | | {} | |
+ blank | Space symbols | | {} | |
asciiword | Word, all ASCII | fat | {english_stem} | english_stem | {fat}
- blank | Space symbols | | {} | |
+ blank | Space symbols | | {} | |
asciiword | Word, all ASCII | cat | {english_stem} | english_stem | {cat}
- blank | Space symbols | | {} | |
+ blank | Space symbols | | {} | |
asciiword | Word, all ASCII | sat | {english_stem} | english_stem | {sat}
- blank | Space symbols | | {} | |
+ blank | Space symbols | | {} | |
asciiword | Word, all ASCII | on | {english_stem} | english_stem | {}
- blank | Space symbols | | {} | |
+ blank | Space symbols | | {} | |
asciiword | Word, all ASCII | a | {english_stem} | english_stem | {}
- blank | Space symbols | | {} | |
+ blank | Space symbols | | {} | |
asciiword | Word, all ASCII | mat | {english_stem} | english_stem | {mat}
- blank | Space symbols | | {} | |
- blank | Space symbols | - | {} | |
+ blank | Space symbols | | {} | |
+ blank | Space symbols | - | {} | |
asciiword | Word, all ASCII | it | {english_stem} | english_stem | {}
- blank | Space symbols | | {} | |
+ blank | Space symbols | | {} | |
asciiword | Word, all ASCII | ate | {english_stem} | english_stem | {ate}
- blank | Space symbols | | {} | |
+ blank | Space symbols | | {} | |
asciiword | Word, all ASCII | a | {english_stem} | english_stem | {}
- blank | Space symbols | | {} | |
+ blank | Space symbols | | {} | |
asciiword | Word, all ASCII | fat | {english_stem} | english_stem | {fat}
- blank | Space symbols | | {} | |
+ blank | Space symbols | | {} | |
asciiword | Word, all ASCII | rats | {english_stem} | english_stem | {rat}
</screen>
</para>
@@ -3273,12 +3273,12 @@ ALTER TEXT SEARCH CONFIGURATION public.english
<screen>
SELECT * FROM ts_debug('public.english','The Brightest supernovaes');
- alias | description | token | dictionaries | dictionary | lexemes
+ alias | description | token | dictionaries | dictionary | lexemes
-----------+-----------------+-------------+-------------------------------+----------------+-------------
asciiword | Word, all ASCII | The | {english_ispell,english_stem} | english_ispell | {}
- blank | Space symbols | | {} | |
+ blank | Space symbols | | {} | |
asciiword | Word, all ASCII | Brightest | {english_ispell,english_stem} | english_ispell | {bright}
- blank | Space symbols | | {} | |
+ blank | Space symbols | | {} | |
asciiword | Word, all ASCII | supernovaes | {english_ispell,english_stem} | english_stem | {supernova}
</screen>
@@ -3312,12 +3312,12 @@ SELECT * FROM ts_debug('public.english','The Brightest supernovaes');
<screen>
SELECT alias, token, dictionary, lexemes
FROM ts_debug('public.english','The Brightest supernovaes');
- alias | token | dictionary | lexemes
+ alias | token | dictionary | lexemes
-----------+-------------+----------------+-------------
asciiword | The | english_ispell | {}
- blank | | |
+ blank | | |
asciiword | Brightest | english_ispell | {bright}
- blank | | |
+ blank | | |
asciiword | supernovaes | english_stem | {supernova}
</screen>
</para>
@@ -3383,7 +3383,7 @@ ts_token_type(<replaceable class="PARAMETER">parser_oid</> <type>oid</>, OUT <re
<screen>
SELECT * FROM ts_token_type('default');
- tokid | alias | description
+ tokid | alias | description
-------+-----------------+------------------------------------------
1 | asciiword | Word, all ASCII
2 | word | Word, all letters
@@ -3646,14 +3646,14 @@ SELECT plainto_tsquery('supernovae stars');
<screen>
=> \dF russian
List of text search configurations
- Schema | Name | Description
+ Schema | Name | Description
------------+---------+------------------------------------
pg_catalog | russian | configuration for russian language
=> \dF+ russian
Text search configuration "pg_catalog.russian"
Parser: "pg_catalog.default"
- Token | Dictionaries
+ Token | Dictionaries
-----------------+--------------
asciihword | english_stem
asciiword | english_stem
@@ -3687,7 +3687,7 @@ Parser: "pg_catalog.default"
<screen>
=> \dFd
List of text search dictionaries
- Schema | Name | Description
+ Schema | Name | Description
------------+-----------------+-----------------------------------------------------------
pg_catalog | danish_stem | snowball stemmer for danish language
pg_catalog | dutch_stem | snowball stemmer for dutch language
@@ -3718,21 +3718,21 @@ Parser: "pg_catalog.default"
<screen>
=> \dFp
List of text search parsers
- Schema | Name | Description
+ Schema | Name | Description
------------+---------+---------------------
pg_catalog | default | default word parser
=> \dFp+
Text search parser "pg_catalog.default"
- Method | Function | Description
+ Method | Function | Description
-----------------+----------------+-------------
- Start parse | prsd_start |
- Get next token | prsd_nexttoken |
- End parse | prsd_end |
- Get headline | prsd_headline |
- Get token types | prsd_lextype |
+ Start parse | prsd_start |
+ Get next token | prsd_nexttoken |
+ End parse | prsd_end |
+ Get headline | prsd_headline |
+ Get token types | prsd_lextype |
Token types for parser "pg_catalog.default"
- Token name | Description
+ Token name | Description
-----------------+------------------------------------------
asciihword | Hyphenated word, all ASCII
asciiword | Word, all ASCII
@@ -3771,7 +3771,7 @@ Parser: "pg_catalog.default"
<screen>
=> \dFt
List of text search templates
- Schema | Name | Description
+ Schema | Name | Description
------------+-----------+-----------------------------------------------------------
pg_catalog | ispell | ispell dictionary
pg_catalog | simple | simple dictionary: just lower case and check for stopword
diff --git a/doc/src/sgml/xaggr.sgml b/doc/src/sgml/xaggr.sgml
index 79a9f28..7bb8e69 100644
--- a/doc/src/sgml/xaggr.sgml
+++ b/doc/src/sgml/xaggr.sgml
@@ -322,7 +322,7 @@ SELECT attrelid::regclass, array_accum(attname)
WHERE attnum > 0 AND attrelid = 'pg_tablespace'::regclass
GROUP BY attrelid;
- attrelid | array_accum
+ attrelid | array_accum
---------------+---------------------------------------
pg_tablespace | {spcname,spcowner,spcacl,spcoptions}
(1 row)
@@ -332,7 +332,7 @@ SELECT attrelid::regclass, array_accum(atttypid::regtype)
WHERE attnum > 0 AND attrelid = 'pg_tablespace'::regclass
GROUP BY attrelid;
- attrelid | array_accum
+ attrelid | array_accum
---------------+---------------------------
pg_tablespace | {name,oid,aclitem[],text[]}
(1 row)
diff --git a/doc/src/sgml/xfunc.sgml b/doc/src/sgml/xfunc.sgml
index f2f3798..182eb32 100644
--- a/doc/src/sgml/xfunc.sgml
+++ b/doc/src/sgml/xfunc.sgml
@@ -675,7 +675,7 @@ CREATE FUNCTION mleast(VARIADIC arr numeric[]) RETURNS numeric AS $$
$$ LANGUAGE SQL;
SELECT mleast(10, -1, 5, 4.4);
- mleast
+ mleast
--------
-1
(1 row)
@@ -775,19 +775,19 @@ AS $$
$$;
SELECT foo(10, 20, 30);
- foo
+ foo
-----
60
(1 row)
SELECT foo(10, 20);
- foo
+ foo
-----
33
(1 row)
SELECT foo(10);
- foo
+ foo
-----
15
(1 row)
@@ -1146,13 +1146,13 @@ CREATE FUNCTION anyleast (VARIADIC anyarray) RETURNS anyelement AS $$
$$ LANGUAGE SQL;
SELECT anyleast(10, -1, 5, 4);
- anyleast
+ anyleast
----------
-1
(1 row)
SELECT anyleast('abc'::text, 'def');
- anyleast
+ anyleast
----------
abc
(1 row)
@@ -1162,7 +1162,7 @@ CREATE FUNCTION concat_values(text, VARIADIC anyarray) RETURNS text AS $$
$$ LANGUAGE SQL;
SELECT concat_values('|', 1, 4, 2);
- concat_values
+ concat_values
---------------
1|4|2
(1 row)
--
2.8.0.rc3.226.g39d4020
Vladimir Rusinov <vrusinov@google.com> writes:
Therefore, I propose this patch.
Right now is a really bad time to do that; what it will mostly accomplish
is to break back-patching of doc fixes for little benefit.
There is work afoot to convert the documentation to xml. If that
succeeds, it'd make sense to strip trailing spaces (and start enforcing
that in .gitattributes) when we do that, since it'll be a back-patch
breakpoint anyway. But right now the PITA factor outweighs the benefit.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
* Tom Lane (tgl@sss.pgh.pa.us) wrote:
Vladimir Rusinov <vrusinov@google.com> writes:
Therefore, I propose this patch.
Right now is a really bad time to do that; what it will mostly accomplish
is to break back-patching of doc fixes for little benefit.There is work afoot to convert the documentation to xml. If that
succeeds, it'd make sense to strip trailing spaces (and start enforcing
that in .gitattributes) when we do that, since it'll be a back-patch
breakpoint anyway. But right now the PITA factor outweighs the benefit.
Almost all of that patch was just removing the whitespace from examples
where the actual commands used produced output with trailing whitespace.
I'm not entirely sure we want to change those cases given that's what we
do, in fact, produce as output. In other words, the trailing whitespace
there isn't just because someone mistakenly included it.
If we do want to change that, perhaps we should also change psql to not
output the trailing whitespace in the first place..?
Thanks!
Stephen
Stephen Frost <sfrost@snowman.net> writes:
If we do want to change that, perhaps we should also change psql to not
output the trailing whitespace in the first place..?
Yeah, maybe. I seem to recall having looked at that a long time ago
and deciding that it wasn't worth the trouble, but the code involved
has probably been restructured since then, so maybe it'd be easier now.
Of course, that would also create a back-patch breakpoint for every
single regression test expected-file, which is doubling down on the
PITA factor in a rather major way.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Dec 14, 2016 at 4:50 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Vladimir Rusinov <vrusinov@google.com> writes:
Therefore, I propose this patch.
Right now is a really bad time to do that; what it will mostly accomplish
is to break back-patching of doc fixes for little benefit.
ack. As I said, it's a proposal and I'm not too attached to it.
Glad it sparked some discussions though.
That said, I don't fully buy this argument: diff is very simple. Merge
conflicts during backporting will be trivial to fix, although a bit more
annoying.
There is work afoot to convert the documentation to xml. If that
succeeds, it'd make sense to strip trailing spaces (and start enforcing
that in .gitattributes) when we do that, since it'll be a back-patch
breakpoint anyway. But right now the PITA factor outweighs the benefit.
What is the ETA for this work to be complete (or fail and be abandoned)?
--
Vladimir Rusinov
Storage SRE, Google Ireland
Google Ireland Ltd.,Gordon House, Barrow Street, Dublin 4, Ireland
Registered in Dublin, Ireland
Registration Number: 368047
Attachments:
* Tom Lane (tgl@sss.pgh.pa.us) wrote:
Stephen Frost <sfrost@snowman.net> writes:
If we do want to change that, perhaps we should also change psql to not
output the trailing whitespace in the first place..?Yeah, maybe. I seem to recall having looked at that a long time ago
and deciding that it wasn't worth the trouble, but the code involved
has probably been restructured since then, so maybe it'd be easier now.Of course, that would also create a back-patch breakpoint for every
single regression test expected-file, which is doubling down on the
PITA factor in a rather major way.
I'm not convinced that any of this is worth the effort. Wouldn't it be
possible, if we are moving the docs to XML, to mark the examples in the
docs in a way similar to LaTeX's 'verbatim' and allow trailing
whitespace there?
We wouldn't be able to use git to complain about trailing whitespace in
the docs then, I don't think, but perhaps we could detect invalid
trailing whitespace when building the docs and complain then. I expect
that most of us build the docs before we commit anything to them anyway.
Thanks!
Stephen
On Wed, Dec 14, 2016 at 5:14 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Stephen Frost <sfrost@snowman.net> writes:
If we do want to change that, perhaps we should also change psql to not
output the trailing whitespace in the first place..?Yeah, maybe. I seem to recall having looked at that a long time ago
and deciding that it wasn't worth the trouble, but the code involved
has probably been restructured since then, so maybe it'd be easier now.
That sounds like a good idea, I guess I can take another look.
I could think of no reason to keep whitespaces there.
Of course, that would also create a back-patch breakpoint for every
single regression test expected-file, which is doubling down on the
PITA factor in a rather major way.
It looks like tests (at least in master) ignore whitespace-only diffs.
So we can handle trailing whitespaces in expected output files as a
separate issue.
One way to ease the pain is to remove trailing whitespaces in all supported
branches via separate patches.
--
Vladimir Rusinov
Storage SRE, Google Ireland
Google Ireland Ltd.,Gordon House, Barrow Street, Dublin 4, Ireland
Registered in Dublin, Ireland
Registration Number: 368047
Attachments:
* Vladimir Rusinov (vrusinov@google.com) wrote:
They are considered bad practice in many style guides and many editors
configured to stip them on every save.Such editors will produce spurious diffs when editing the documentation.
Therefore, I propose this patch.
As mentioned down-thread, most of this is from psql output and I don't
know that we actually want to get rid of that whitespace. Ideally, we
could indicate that trailing whitespace should be preserved when
printing examples, either with the SGML or the XML format.
The (relativly few) ones I include below do look like cases we should
probably fix and back-patch (to simplify later back-patching efforts).
Most of these only go back to 9.6 (parallel.sgml) anyway.
Thanks!
Stephen
Show quoted text
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 @@ -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 --- 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">
On Wed, Dec 14, 2016 at 5:41 PM, Stephen Frost <sfrost@snowman.net> wrote:
They are considered bad practice in many style guides and many editors
configured to stip them on every save.Such editors will produce spurious diffs when editing the documentation.
Therefore, I propose this patch.
As mentioned down-thread, most of this is from psql output and I don't
know that we actually want to get rid of that whitespace. Ideally, we
could indicate that trailing whitespace should be preserved when
printing examples, either with the SGML or the XML format.The (relativly few) ones I include below do look like cases we should
probably fix and back-patch (to simplify later back-patching efforts).
Most of these only go back to 9.6 (parallel.sgml) anyway.
I'm not sure if it makes sense to merge just these, as it will not help
people with whitespace-eating editors.
--
Vladimir Rusinov
Storage SRE, Google Ireland
Google Ireland Ltd.,Gordon House, Barrow Street, Dublin 4, Ireland
Registered in Dublin, Ireland
Registration Number: 368047
Attachments:
* Vladimir Rusinov (vrusinov@google.com) wrote:
I'm not sure if it makes sense to merge just these, as it will not help
people with whitespace-eating editors.
I think we've established that it's going to be quite a while before we
will reach a point where whitespace-eating editors aren't a problem when
it comes to working with our docs.
That doesn't mean we shouldn't fix obviously incorrect trailing
whitespace in the docs.
Thanks!
Stephen
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:
/messages/by-id/1285093687.5468.18.camel@vanquo.pezone.net
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
* Peter Eisentraut (peter.eisentraut@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:
/messages/by-id/1285093687.5468.18.camel@vanquo.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!
Stephen
Stephen Frost <sfrost@snowman.net> writes:
* Peter Eisentraut (peter.eisentraut@2ndquadrant.com) wrote:
Previous discussion:
/messages/by-id/1285093687.5468.18.camel@vanquo.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..).
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.
The way I read that thread is that people were left feeling that it
was probably more work than it was worth. That's what I'm thinking,
anyway.
Thinking about this, I'm wondering what is the connection between
what psql does and what should be in the SGML (or XML) docs, anyway.
Nobody says boo when we have to do s/</</g to an example in order
to put it in the docs; why is stripping trailing whitespace a bigger
issue?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 12/14/16 4:51 PM, Tom Lane wrote:
Thinking about this, I'm wondering what is the connection between
what psql does and what should be in the SGML (or XML) docs, anyway.
Nobody says boo when we have to do s/</</g to an example in order
to put it in the docs; why is stripping trailing whitespace a bigger
issue?
There is a previous discussion for that, too, equally inconclusive:
/messages/by-id/1383707883.10722.5.camel@vanquo.pezone.net
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Tom,
* Tom Lane (tgl@sss.pgh.pa.us) wrote:
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.
I agree, that'd be annoying. Having to rewrite the fix for dumping
casts with pg_dump for every single major version we support because the
patch from the prior version couldn't be applied has certainly been a
rather annoying exercise.
Thinking about this, I'm wondering what is the connection between
what psql does and what should be in the SGML (or XML) docs, anyway.
Nobody says boo when we have to do s/</</g to an example in order
to put it in the docs; why is stripping trailing whitespace a bigger
issue?
For my 2c, at least, because we're going to be constantly fighting with
the trailing whitespace in those examples. If you forget to s/</</g,
the docs aren't going to build and it's going to be extremely obvious
that you need to do something. Not that I'm actually happy about that-
I'd much rather tell the doc engine "copy this verbatim until you see a
</closeverbatim> tag" or whatever, and not have to go hack up psql
output at all, which I contend is also rather tedious and annoying to do
when writing new code and new tests. Is that worse than having to deal
with back-patching regression test output? Who knows.
That said, if we can make git complain about trailing whitespace in the
docs but not mind it in the regression test output, then at least most
will hopefully realize that they need to go through and strip out the
trailing whitespace before committing. Maybe we can come up with a psql
output mode of "make this work for the docs" or a tool to pipe arbitrary
text through to have it "do the right thing" for including it in the
docs.
I'm still a bit split, as I do feel like it's 'bad' of psql to be
emitting the trailing whitespace in the first place, even if it's been
done that way forever and even though it'll be an annoyance if we
change it. Ultimately, I'm alright with either way though, I just don't
like the idea of removing all the whitespace from the docs without a way
to minimize the chance that we end up adding it back due to copy/paste
from psql output.
Thanks!
Stephen
Tom Lane wrote:
Thinking about this, I'm wondering what is the connection between
what psql does and what should be in the SGML (or XML) docs, anyway.
Nobody says boo when we have to do s/</</g to an example in order
to put it in the docs; why is stripping trailing whitespace a bigger
issue?
Why do we need to put regular psql output verbatim in SGML/XML? One
idea is to add an output format to psql for docbook table markup, then
use that whenever we need to paste stuff into the docs.
--
�lvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Alvaro,
* Alvaro Herrera (alvherre@2ndquadrant.com) wrote:
Tom Lane wrote:
Thinking about this, I'm wondering what is the connection between
what psql does and what should be in the SGML (or XML) docs, anyway.
Nobody says boo when we have to do s/</</g to an example in order
to put it in the docs; why is stripping trailing whitespace a bigger
issue?Why do we need to put regular psql output verbatim in SGML/XML? One
idea is to add an output format to psql for docbook table markup, then
use that whenever we need to paste stuff into the docs.
I do tend to like this idea.
Though, if we want to talk about writing lots of new code, what I really
like is the pgBackrest doc building system, which actually executes
pgBackrest during the documentation build process to run the commands
and get exactly what they produce included in the docs. There's been
more than one example of *incorrect* hacking up of the example in the
docs, to the point where the example doesn't actually run, just this
year.
Perhaps if the regression tests ran the examples and produced the output
in a way which could be included in the docs...
Thanks!
Stephen
On Wed, Dec 14, 2016 at 9:37 PM, Stephen Frost <sfrost@snowman.net> wrote:
* Peter Eisentraut (peter.eisentraut@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:
/messages/by-id/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
Attachments:
0001-Remove-some-of-the-trailing-whitespaces-from-documen.patchtext/x-patch; charset=US-ASCII; name=0001-Remove-some-of-the-trailing-whitespaces-from-documen.patchDownload
From 80cf7ee7f71c95c89e0908512e41154daff74d3a Mon Sep 17 00:00:00 2001
From: Vladimir Rusinov <vrusinov@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 <vrusinov@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
On 12/14/16 5:12 PM, Stephen Frost wrote:
For my 2c, at least, because we're going to be constantly fighting with
the trailing whitespace in those examples. If you forget to s/</</g,
the docs aren't going to build and it's going to be extremely obvious
that you need to do something. Not that I'm actually happy about that-
I'd much rather tell the doc engine "copy this verbatim until you see a
</closeverbatim> tag" or whatever, and not have to go hack up psql
output at all,
This already exists: git grep -w CDATA
That said, if we can make git complain about trailing whitespace in the
docs but not mind it in the regression test output, then at least most
will hopefully realize that they need to go through and strip out the
trailing whitespace before committing.
That would be easy to do.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 12/14/16 6:10 PM, Vladimir Rusinov wrote:
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.
committed
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers