aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rw-r--r--doc/src/sgml/catalogs.sgml4
-rw-r--r--doc/src/sgml/docguide.sgml4
-rw-r--r--doc/src/sgml/ecpg.sgml6
-rw-r--r--doc/src/sgml/fdwhandler.sgml14
-rw-r--r--doc/src/sgml/file-fdw.sgml4
-rw-r--r--doc/src/sgml/func.sgml12
-rw-r--r--doc/src/sgml/gin.sgml6
-rw-r--r--doc/src/sgml/gist.sgml2
-rw-r--r--doc/src/sgml/indexam.sgml2
-rw-r--r--doc/src/sgml/libpq.sgml2
-rw-r--r--doc/src/sgml/maintenance.sgml4
-rw-r--r--doc/src/sgml/monitoring.sgml26
-rw-r--r--doc/src/sgml/perform.sgml28
-rw-r--r--doc/src/sgml/pgrowlocks.sgml8
-rw-r--r--doc/src/sgml/pgtestfsync.sgml2
-rw-r--r--doc/src/sgml/pgtesttiming.sgml4
-rw-r--r--doc/src/sgml/protocol.sgml4
-rw-r--r--doc/src/sgml/rangetypes.sgml2
-rw-r--r--doc/src/sgml/ref/psql-ref.sgml20
-rw-r--r--doc/src/sgml/rules.sgml6
-rw-r--r--doc/src/sgml/sepgsql.sgml4
-rw-r--r--doc/src/sgml/spgist.sgml10
-rw-r--r--doc/src/sgml/textsearch.sgml4
-rw-r--r--doc/src/sgml/xfunc.sgml2
24 files changed, 90 insertions, 90 deletions
diff --git a/doc/src/sgml/catalogs.sgml b/doc/src/sgml/catalogs.sgml
index 0f0a10f63c7..b00bcf0b6af 100644
--- a/doc/src/sgml/catalogs.sgml
+++ b/doc/src/sgml/catalogs.sgml
@@ -3886,7 +3886,7 @@
particular operator family is applicable to a particular indexable column
data type. The set of operators from the family that are actually usable
with the indexed column are whichever ones accept the column's data type
- as their lefthand input.
+ as their left-hand input.
</para>
<para>
@@ -4431,7 +4431,7 @@
The function has no side effects. No information about the
arguments is conveyed except via the return value. Any function
that might throw an error depending on the values of its arguments
- is not leakproof.
+ is not leak-proof.
</entry>
</row>
diff --git a/doc/src/sgml/docguide.sgml b/doc/src/sgml/docguide.sgml
index 8aaafb0a340..27fb3ef255e 100644
--- a/doc/src/sgml/docguide.sgml
+++ b/doc/src/sgml/docguide.sgml
@@ -317,12 +317,12 @@ make install
<note>
<para>
Some users have reported encountering a segmentation fault using
- openjade 1.4devel to build the PDFs, with a message like:
+ OpenJade 1.4devel to build the PDFs, with a message like:
<screen>
openjade:./stylesheet.dsl:664:2:E: flow object not accepted by port; only display flow objects accepted
make: *** [postgres-A4.tex-pdf] Segmentation fault
</screen>
- Downgrading to openjade 1.3 should get rid of this error.
+ Downgrading to OpenJade 1.3 should get rid of this error.
</para>
</note>
diff --git a/doc/src/sgml/ecpg.sgml b/doc/src/sgml/ecpg.sgml
index 2c5c330023b..934ffe88dd1 100644
--- a/doc/src/sgml/ecpg.sgml
+++ b/doc/src/sgml/ecpg.sgml
@@ -2752,7 +2752,7 @@ timestamp PGTYPEStimestamp_from_asc(char *str, char **endptr);
<para>
In general, the input string can contain any combination of an allowed
date specification, a whitespace character and an allowed time
- specification. Note that timezones are not supported by ECPG. It can
+ specification. Note that time zones are not supported by ECPG. It can
parse them but does not apply any calculation as the
<productname>PostgreSQL</> server does for example. Timezone
specifiers are silently discarded.
@@ -9164,7 +9164,7 @@ int rtypwidth(int sqltype, int sqllen);
int rsetnull(int t, char *ptr);
</synopsis>
The function receives an integer that indicates the type of the
- variable and a pointer to the variable itself that is casted to a C
+ variable and a pointer to the variable itself that is cast to a C
char* pointer.
</para>
<para>
@@ -9249,7 +9249,7 @@ int risnull(int t, char *ptr);
</synopsis>
The function receives the type of the variable to test (<literal>t</>)
as well a pointer to this variable (<literal>ptr</>). Note that the
- latter needs to be casted to a char*. See the function <xref
+ latter needs to be cast to a char*. See the function <xref
linkend="rsetnull"> for a list of possible variable types.
</para>
<para>
diff --git a/doc/src/sgml/fdwhandler.sgml b/doc/src/sgml/fdwhandler.sgml
index 2c75b80b303..8f1782882ff 100644
--- a/doc/src/sgml/fdwhandler.sgml
+++ b/doc/src/sgml/fdwhandler.sgml
@@ -191,7 +191,7 @@ ExplainForeignScan (ForeignScanState *node,
related functions to add fields to the <command>EXPLAIN</> output.
The flag fields in <literal>es</> can be used to determine what to
print, and the state of the <structname>ForeignScanState</> node
- can be inspected to provide runtime statistics in the <command>EXPLAIN
+ can be inspected to provide run-time statistics in the <command>EXPLAIN
ANALYZE</> case.
</para>
@@ -489,20 +489,20 @@ GetForeignServerByName(const char *name, bool missing_ok);
The <structfield>fdw_private</> list has no other restrictions and is
not interpreted by the core backend in any way. The
<structfield>fdw_exprs</> list, if not NIL, is expected to contain
- expression trees that are intended to be executed at runtime. These
+ expression trees that are intended to be executed at run time. These
trees will undergo post-processing by the planner to make them fully
executable.
</para>
<para>
- In <function>GetForeignPlan</>, generally the passed-in targetlist can
+ In <function>GetForeignPlan</>, generally the passed-in target list can
be copied into the plan node as-is. The passed scan_clauses list
contains the same clauses as <literal>baserel-&gt;baserestrictinfo</>,
but may be re-ordered for better execution efficiency. In simple cases
the FDW can just strip <structname>RestrictInfo</> nodes from the
scan_clauses list (using <function>extract_actual_clauses</>) and put
all the clauses into the plan node's qual list, which means that all the
- clauses will be checked by the executor at runtime. More complex FDWs
+ clauses will be checked by the executor at run time. More complex FDWs
may be able to check some of the clauses internally, in which case those
clauses can be removed from the plan node's qual list so that the
executor doesn't waste time rechecking them.
@@ -523,9 +523,9 @@ GetForeignServerByName(const char *name, bool missing_ok);
to ensure that it gets massaged into executable form. It would probably
also put control information into the plan node's
<structfield>fdw_private</> field to tell the execution functions what
- to do at runtime. The query transmitted to the remote server would
+ to do at run time. The query transmitted to the remote server would
involve something like <literal>WHERE <replaceable>foreign_variable</> =
- $1</literal>, with the parameter value obtained at runtime from
+ $1</literal>, with the parameter value obtained at run time from
evaluation of the <structfield>fdw_exprs</> expression tree.
</para>
@@ -541,7 +541,7 @@ GetForeignServerByName(const char *name, bool missing_ok);
<literal>required_outer</> and list the specific join clause(s) in
<literal>param_clauses</>. In <function>GetForeignPlan</>, the
<replaceable>local_variable</> portion of the join clause would be added
- to <structfield>fdw_exprs</>, and then at runtime the case works the
+ to <structfield>fdw_exprs</>, and then at run time the case works the
same as for an ordinary restriction clause.
</para>
diff --git a/doc/src/sgml/file-fdw.sgml b/doc/src/sgml/file-fdw.sgml
index 35d344f5c89..889aa778d7a 100644
--- a/doc/src/sgml/file-fdw.sgml
+++ b/doc/src/sgml/file-fdw.sgml
@@ -122,7 +122,7 @@
<listitem>
<para>
- This is a boolean option. If true, it specifies that values of the
+ This is a Boolean option. If true, it specifies that values of the
column should not be matched against the null string (that is, the
file-level <literal>null</literal> option). This has the same effect
as listing the column in <command>COPY</>'s
@@ -184,7 +184,7 @@ CREATE SERVER pglog FOREIGN DATA WRAPPER file_fdw;
<para>
Now you are ready to create the foreign data table. Using the
<command>CREATE FOREIGN TABLE</> command, you will need to define
- the columns for the table, the CSV filename, and its format:
+ the columns for the table, the CSV file name, and its format:
<programlisting>
CREATE FOREIGN TABLE pglog (
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 29538888cb5..de13c7c4761 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -9648,9 +9648,9 @@ table2-mapping
<literal>array_to_json(anyarray [, pretty_bool])</literal>
</entry>
<entry>
- Returns the array as JSON. A Postgres multi-dimensional array
+ Returns the array as JSON. A PostgreSQL multidimensional array
becomes a JSON array of arrays. Line feeds will be added between
- dimension 1 elements if pretty_bool is true.
+ dimension 1 elements if <parameter>pretty_bool</parameter> is true.
</entry>
<entry><literal>array_to_json('{{1,5},{99,100}}'::int[])</literal></entry>
<entry><literal>[[1,5],[99,100]]</literal></entry>
@@ -9664,7 +9664,7 @@ table2-mapping
</entry>
<entry>
Returns the row as JSON. Line feeds will be added between level
- 1 elements if pretty_bool is true.
+ 1 elements if <parameter>pretty_bool</parameter> is true.
</entry>
<entry><literal>row_to_json(row(1,'foo'))</literal></entry>
<entry><literal>{"f1":1,"f2":"foo"}</literal></entry>
@@ -13813,7 +13813,7 @@ SELECT pg_type_is_visible('myschema.widget'::regtype);
<entry><literal><function>pg_get_viewdef(<parameter>view_name</parameter>, <parameter>pretty_bool</>)</function></literal></entry>
<entry><type>text</type></entry>
<entry>get underlying <command>SELECT</command> command for view,
- lines with fields are wrapped to 80 columns if pretty_bool is true (<emphasis>deprecated</emphasis>)</entry>
+ lines with fields are wrapped to 80 columns if <parameter>pretty_bool</parameter> is true (<emphasis>deprecated</emphasis>)</entry>
</row>
<row>
<entry><literal><function>pg_get_viewdef(<parameter>view_oid</parameter>)</function></literal></entry>
@@ -13824,7 +13824,7 @@ SELECT pg_type_is_visible('myschema.widget'::regtype);
<entry><literal><function>pg_get_viewdef(<parameter>view_oid</parameter>, <parameter>pretty_bool</>)</function></literal></entry>
<entry><type>text</type></entry>
<entry>get underlying <command>SELECT</command> command for view,
- lines with fields are wrapped to 80 columns if pretty_bool is true</entry>
+ lines with fields are wrapped to 80 columns if <parameter>pretty_bool</parameter> is true</entry>
</row>
<row>
<entry><literal><function>pg_get_viewdef(<parameter>view_oid</parameter>, <parameter>wrap_int</>)</function></literal></entry>
@@ -13845,7 +13845,7 @@ SELECT pg_type_is_visible('myschema.widget'::regtype);
<row>
<entry><literal><function>pg_tablespace_location(<parameter>tablespace_oid</parameter>)</function></literal></entry>
<entry><type>text</type></entry>
- <entry>get the path in the filesystem that this tablespace is located in</entry>
+ <entry>get the path in the file system that this tablespace is located in</entry>
</row>
<row>
<entry><literal><function>pg_typeof(<parameter>any</parameter>)</function></literal></entry>
diff --git a/doc/src/sgml/gin.sgml b/doc/src/sgml/gin.sgml
index 7b4d9c4e9e1..ca7641a8390 100644
--- a/doc/src/sgml/gin.sgml
+++ b/doc/src/sgml/gin.sgml
@@ -107,9 +107,9 @@
If any of the keys can be null, also palloc an array of
<literal>*nkeys</> booleans, store its address at
<literal>*nullFlags</>, and set these null flags as needed.
- <literal>*nullFlags</> can be left NULL (its initial value)
+ <literal>*nullFlags</> can be left <symbol>NULL</symbol> (its initial value)
if all keys are non-null.
- The return value can be NULL if the item contains no keys.
+ The return value can be <symbol>NULL</symbol> if the item contains no keys.
</para>
</listitem>
</varlistentry>
@@ -313,7 +313,7 @@
</para>
<para>
- Multi-column <acronym>GIN</acronym> indexes are implemented by building
+ Multicolumn <acronym>GIN</acronym> indexes are implemented by building
a single B-tree over composite values (column number, key value). The
key values for different columns can be of different types.
</para>
diff --git a/doc/src/sgml/gist.sgml b/doc/src/sgml/gist.sgml
index 73bf63fd3a3..ed0bc54f52d 100644
--- a/doc/src/sgml/gist.sgml
+++ b/doc/src/sgml/gist.sgml
@@ -665,7 +665,7 @@ my_distance(PG_FUNCTION_ARGS)
a lot of random I/O. Beginning in version 9.2, PostgreSQL supports a more
efficient method to build GiST indexes based on buffering, which can
dramatically reduce the number of random I/Os needed for non-ordered data
- sets. For well-ordered datasets the benefit is smaller or non-existent,
+ sets. For well-ordered data sets the benefit is smaller or non-existent,
because only a small number of pages receive new tuples at a time, and
those pages fit in cache even if the index as whole does not.
</para>
diff --git a/doc/src/sgml/indexam.sgml b/doc/src/sgml/indexam.sgml
index 28f2ae16275..e03ebc93680 100644
--- a/doc/src/sgml/indexam.sgml
+++ b/doc/src/sgml/indexam.sgml
@@ -363,7 +363,7 @@ amrescan (IndexScanDesc scan,
ScanKey orderbys,
int norderbys);
</programlisting>
- Start or restart an indexscan, possibly with new scan keys. (To restart
+ Start or restart an index scan, possibly with new scan keys. (To restart
using previously-passed keys, NULL is passed for <literal>keys</> and/or
<literal>orderbys</>.) Note that it is not allowed for
the number of keys or order-by operators to be larger than
diff --git a/doc/src/sgml/libpq.sgml b/doc/src/sgml/libpq.sgml
index ef1d95ed204..5c5dd68db30 100644
--- a/doc/src/sgml/libpq.sgml
+++ b/doc/src/sgml/libpq.sgml
@@ -805,7 +805,7 @@ postgresql:///mydb?host=localhost&amp;port=5433
</para>
<para>
- The host part may be either hostname or an IP address. To specify an
+ The host part may be either host name or an IP address. To specify an
IPv6 host address, enclose it in square brackets:
<synopsis>
postgresql://[2001:db8::1234]/database
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index cc33e5f76b0..fb705b2cbb6 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -865,10 +865,10 @@ pg_ctl start | rotatelogs /var/log/pgsql_log 86400
</para>
<para>
- <ulink url="http://pgfouine.projects.postgresql.org/">pgFouine</ulink>
+ <ulink url="http://pgfouine.projects.postgresql.org/"><productname>pgFouine</productname></ulink>
is an external project that does sophisticated log file analysis.
<ulink
- url="http://bucardo.org/wiki/Check_postgres">check_postgres</ulink>
+ url="http://bucardo.org/wiki/Check_postgres"><productname>check_postgres</productname></ulink>
provides Nagios alerts when important messages appear in the log
files, as well as detection of many other extraordinary conditions.
</para>
diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml
index 830f6217d2e..39ccfbb8434 100644
--- a/doc/src/sgml/monitoring.sgml
+++ b/doc/src/sgml/monitoring.sgml
@@ -210,7 +210,7 @@ postgres: <replaceable>user</> <replaceable>database</> <replaceable>host</> <re
the collector just before going idle; so a query or transaction still in
progress does not affect the displayed totals. Also, the collector itself
emits a new report at most once per <varname>PGSTAT_STAT_INTERVAL</varname>
- milliseconds (500 msec unless altered while building the server). So the
+ milliseconds (500 ms unless altered while building the server). So the
displayed information lags behind actual activity. However, current-query
information collected by <varname>track_activities</varname> is
always up-to-date.
@@ -472,7 +472,7 @@ postgres: <replaceable>user</> <replaceable>database</> <replaceable>host</> <re
<table id="pg-stat-activity-view" xreflabel="pg_stat_activity">
- <title>pg_stat_activity view</title>
+ <title><structname>pg_stat_activity</structname> View</title>
<tgroup cols="3">
<thead>
@@ -649,7 +649,7 @@ postgres: <replaceable>user</> <replaceable>database</> <replaceable>host</> <re
</note>
<table id="pg-stat-bgwriter-view" xreflabel="pg_stat_bgwriter">
- <title>pg_stat_bgwriter view</title>
+ <title><structname>pg_stat_bgwriter</structname> View</title>
<tgroup cols="3">
<thead>
@@ -736,7 +736,7 @@ postgres: <replaceable>user</> <replaceable>database</> <replaceable>host</> <re
</para>
<table id="pg-stat-database-view" xreflabel="pg_stat_database">
- <title>pg_stat_database view</title>
+ <title><structname>pg_stat_database</structname> View</title>
<tgroup cols="3">
<thead>
<row>
@@ -787,7 +787,7 @@ postgres: <replaceable>user</> <replaceable>database</> <replaceable>host</> <re
<entry><type>bigint</></entry>
<entry>Number of times disk blocks were found already in the buffer
cache, so that a read was not necessary (this only includes hits in the
- PostgreSQL buffer cache, not the operating system's filesystem cache)
+ PostgreSQL buffer cache, not the operating system's file system cache)
</entry>
</row>
<row>
@@ -873,7 +873,7 @@ postgres: <replaceable>user</> <replaceable>database</> <replaceable>host</> <re
</para>
<table id="pg-stat-all-tables-view" xreflabel="pg_stat_all_tables">
- <title>pg_stat_all_tables view</title>
+ <title><structname>pg_stat_all_tables</structname> View</title>
<tgroup cols="3">
<thead>
<row>
@@ -1011,7 +1011,7 @@ postgres: <replaceable>user</> <replaceable>database</> <replaceable>host</> <re
</para>
<table id="pg-stat-all-indexes-view" xreflabel="pg_stat_all_indexes">
- <title>pg_stat_all_indexes view</title>
+ <title><structname>pg_stat_all_indexes</structname> View</title>
<tgroup cols="3">
<thead>
<row>
@@ -1104,7 +1104,7 @@ postgres: <replaceable>user</> <replaceable>database</> <replaceable>host</> <re
</note>
<table id="pg-statio-all-tables-view" xreflabel="pg_statio_all_tables">
- <title>pg_statio_all_tables view</title>
+ <title><structname>pg_statio_all_tables</structname> View</title>
<tgroup cols="3">
<thead>
<row>
@@ -1185,7 +1185,7 @@ postgres: <replaceable>user</> <replaceable>database</> <replaceable>host</> <re
</para>
<table id="pg-statio-all-indexes-view" xreflabel="pg_statio_all_indexes">
- <title>pg_statio_all_indexes view</title>
+ <title><structname>pg_statio_all_indexes</structname> View</title>
<tgroup cols="3">
<thead>
<row>
@@ -1246,7 +1246,7 @@ postgres: <replaceable>user</> <replaceable>database</> <replaceable>host</> <re
</para>
<table id="pg-statio-all-sequences-view" xreflabel="pg_statio_all_sequences">
- <title>pg_statio_all_sequences view</title>
+ <title><structname>pg_statio_all_sequences</structname> View</title>
<tgroup cols="3">
<thead>
<row>
@@ -1293,7 +1293,7 @@ postgres: <replaceable>user</> <replaceable>database</> <replaceable>host</> <re
</para>
<table id="pg-stat-user-functions-view" xreflabel="pg_stat_user_functions">
- <title>pg_stat_user_functions view</title>
+ <title><structname>pg_stat_user_functions</structname> View</title>
<tgroup cols="3">
<thead>
<row>
@@ -1348,7 +1348,7 @@ postgres: <replaceable>user</> <replaceable>database</> <replaceable>host</> <re
</para>
<table id="pg-stat-replication-view" xreflabel="pg_stat_replication">
- <title>pg_stat_replication view</title>
+ <title><structname>pg_stat_replication</structname> View</title>
<tgroup cols="3">
<thead>
<row>
@@ -1462,7 +1462,7 @@ postgres: <replaceable>user</> <replaceable>database</> <replaceable>host</> <re
</para>
<table id="pg-stat-database-conflicts-view" xreflabel="pg_stat_database_conflicts">
- <title>pg_stat_database_conflicts view</title>
+ <title><structname>pg_stat_database_conflicts</structname> View</title>
<tgroup cols="3">
<thead>
<row>
diff --git a/doc/src/sgml/perform.sgml b/doc/src/sgml/perform.sgml
index 5a8c6fc7dc8..1e7544afeb4 100644
--- a/doc/src/sgml/perform.sgml
+++ b/doc/src/sgml/perform.sgml
@@ -265,7 +265,7 @@ EXPLAIN SELECT * FROM tenk1 WHERE unique1 &lt; 100 AND stringu1 = 'xxx';
</screen>
The added condition <literal>stringu1 = 'xxx'</literal> reduces the
- output-rowcount estimate, but not the cost because we still have to visit
+ output row count estimate, but not the cost because we still have to visit
the same set of rows. Notice that the <literal>stringu1</> clause
cannot be applied as an index condition, since this index is only on
the <literal>unique1</> column. Instead it is applied as a filter on
@@ -385,7 +385,7 @@ WHERE t1.unique1 &lt; 10 AND t1.unique2 = t2.unique2;
<literal>SELECT ... WHERE t2.unique2 = <replaceable>constant</></> case.
(The estimated cost is actually a bit lower than what was seen above,
as a result of caching that's expected to occur during the repeated
- indexscans on <literal>t2</>.) The
+ index scans on <literal>t2</>.) The
costs of the loop node are then set on the basis of the cost of the outer
scan, plus one repetition of the inner scan for each outer row (10 * 7.87,
here), plus a little CPU time for join processing.
@@ -489,8 +489,8 @@ WHERE t1.unique1 &lt; 100 AND t1.unique2 = t2.unique2;
the rows in the correct order, but a sequential scan and sort is preferred
for <literal>onek</>, because there are many more rows to be visited in
that table.
- (Seqscan-and-sort frequently beats an indexscan for sorting many rows,
- because of the nonsequential disk access required by the indexscan.)
+ (Sequential-scan-and-sort frequently beats an index scan for sorting many rows,
+ because of the nonsequential disk access required by the index scan.)
</para>
<para>
@@ -499,7 +499,7 @@ WHERE t1.unique1 &lt; 100 AND t1.unique2 = t2.unique2;
flags described in <xref linkend="runtime-config-query-enable">.
(This is a crude tool, but useful. See
also <xref linkend="explicit-joins">.)
- For example, if we're unconvinced that seqscan-and-sort is the best way to
+ For example, if we're unconvinced that sequential-scan-and-sort is the best way to
deal with table <literal>onek</> in the previous example, we could try
<screen>
@@ -519,7 +519,7 @@ WHERE t1.unique1 &lt; 100 AND t1.unique2 = t2.unique2;
</screen>
which shows that the planner thinks that sorting <literal>onek</> by
- indexscanning is about 12% more expensive than seqscan-and-sort.
+ index-scanning is about 12% more expensive than sequential-scan-and-sort.
Of course, the next question is whether it's right about that.
We can investigate that using <command>EXPLAIN ANALYZE</>, as discussed
below.
@@ -573,7 +573,7 @@ WHERE t1.unique1 &lt; 10 AND t1.unique2 = t2.unique2;
comparable with the way that the cost estimates are shown. Multiply by
the <literal>loops</> value to get the total time actually spent in
the node. In the above example, we spent a total of 0.480 milliseconds
- executing the indexscans on <literal>tenk2</>.
+ executing the index scans on <literal>tenk2</>.
</para>
<para>
@@ -634,7 +634,7 @@ EXPLAIN ANALYZE SELECT * FROM tenk1 WHERE ten &lt; 7;
<para>
A case similar to filter conditions occurs with <quote>lossy</>
- indexscans. For example, consider this search for polygons containing a
+ index scans. For example, consider this search for polygons containing a
specific point:
<screen>
@@ -649,9 +649,9 @@ EXPLAIN ANALYZE SELECT * FROM polygon_tbl WHERE f1 @&gt; polygon '(0.5,2.0)';
</screen>
The planner thinks (quite correctly) that this sample table is too small
- to bother with an indexscan, so we have a plain sequential scan in which
+ to bother with an index scan, so we have a plain sequential scan in which
all the rows got rejected by the filter condition. But if we force an
- indexscan to be used, we see:
+ index scan to be used, we see:
<screen>
SET enable_seqscan TO off;
@@ -808,9 +808,9 @@ EXPLAIN ANALYZE SELECT * FROM tenk1 WHERE unique1 &lt; 100 AND unique2 &gt; 9000
Total runtime: 2.857 ms
</screen>
- the estimated cost and rowcount for the Index Scan node are shown as
+ the estimated cost and row count for the Index Scan node are shown as
though it were run to completion. But in reality the Limit node stopped
- requesting rows after it got two, so the actual rowcount is only 2 and
+ requesting rows after it got two, so the actual row count is only 2 and
the runtime is less than the cost estimate would suggest. This is not
an estimation error, only a discrepancy in the way the estimates and true
values are displayed.
@@ -827,13 +827,13 @@ EXPLAIN ANALYZE SELECT * FROM tenk1 WHERE unique1 &lt; 100 AND unique2 &gt; 9000
the inner (second) child is backed up and rescanned for the portion of its
rows matching that key value. <command>EXPLAIN ANALYZE</> counts these
repeated emissions of the same inner rows as if they were real additional
- rows. When there are many outer duplicates, the reported actual rowcount
+ rows. When there are many outer duplicates, the reported actual row count
for the inner child plan node can be significantly larger than the number
of rows that are actually in the inner relation.
</para>
<para>
- BitmapAnd and BitmapOr nodes always report their actual rowcounts as zero,
+ BitmapAnd and BitmapOr nodes always report their actual row counts as zero,
due to implementation limitations.
</para>
</sect2>
diff --git a/doc/src/sgml/pgrowlocks.sgml b/doc/src/sgml/pgrowlocks.sgml
index db1cf5e863d..390fa236d31 100644
--- a/doc/src/sgml/pgrowlocks.sgml
+++ b/doc/src/sgml/pgrowlocks.sgml
@@ -52,22 +52,22 @@ pgrowlocks(text) returns setof record
<row>
<entry><structfield>locker</structfield></entry>
<entry><type>xid</type></entry>
- <entry>Transaction ID of locker, or multixact ID if multi-transaction</entry>
+ <entry>Transaction ID of locker, or multixact ID if multitransaction</entry>
</row>
<row>
<entry><structfield>multi</structfield></entry>
<entry><type>boolean</type></entry>
- <entry>True if locker is a multi-transaction</entry>
+ <entry>True if locker is a multitransaction</entry>
</row>
<row>
<entry><structfield>xids</structfield></entry>
<entry><type>xid[]</type></entry>
- <entry>Transaction IDs of lockers (more than one if multi-transaction)</entry>
+ <entry>Transaction IDs of lockers (more than one if multitransaction)</entry>
</row>
<row>
<entry><structfield>pids</structfield></entry>
<entry><type>integer[]</type></entry>
- <entry>Process IDs of locking backends (more than one if multi-transaction)</entry>
+ <entry>Process IDs of locking backends (more than one if multitransaction)</entry>
</row>
</tbody>
diff --git a/doc/src/sgml/pgtestfsync.sgml b/doc/src/sgml/pgtestfsync.sgml
index ad5ddeb2288..d8c0c458088 100644
--- a/doc/src/sgml/pgtestfsync.sgml
+++ b/doc/src/sgml/pgtestfsync.sgml
@@ -31,7 +31,7 @@
idea of what the fastest <xref linkend="guc-wal-sync-method"> is on your
specific system,
as well as supplying diagnostic information in the event of an
- identified I/O problem. However, differences shown by pg_test_fsync
+ identified I/O problem. However, differences shown by <application>pg_test_fsync</application>
might not make any difference in real database throughput, especially
since many database servers are not speed-limited by their transaction
logs.
diff --git a/doc/src/sgml/pgtesttiming.sgml b/doc/src/sgml/pgtesttiming.sgml
index 784f866b8d9..486be831237 100644
--- a/doc/src/sgml/pgtesttiming.sgml
+++ b/doc/src/sgml/pgtesttiming.sgml
@@ -101,7 +101,7 @@ Histogram of timing durations:
When the query executor is running a statement using
<command>EXPLAIN ANALYZE</command>, individual operations are timed as well
as showing a summary. The overhead of your system can be checked by
- counting rows with the psql program:
+ counting rows with the <application>psql</application> program:
<screen>
CREATE TABLE t AS SELECT * FROM generate_series(1,100000);
@@ -226,7 +226,7 @@ Histogram of timing durations:
reliable. There are several ways that TSC can fail to provide an accurate
timing source, making it unreliable. Older systems can have a TSC clock that
varies based on the CPU temperature, making it unusable for timing. Trying
- to use TSC on some older multi-core CPUs can give a reported time that's
+ to use TSC on some older multicore CPUs can give a reported time that's
inconsistent among multiple cores. This can result in the time going
backwards, a problem this program checks for. And even the newest systems
can fail to provide accurate TSC timing with very aggressive power saving
diff --git a/doc/src/sgml/protocol.sgml b/doc/src/sgml/protocol.sgml
index 71c40cc592e..e72556303ab 100644
--- a/doc/src/sgml/protocol.sgml
+++ b/doc/src/sgml/protocol.sgml
@@ -1783,13 +1783,13 @@ The commands accepted in walsender mode are:
<listitem>
<para>
<filename>pg_xlog</>, including subdirectories. If the backup is run
- with wal files included, a synthesized version of pg_xlog will be
+ with WAL files included, a synthesized version of <filename>pg_xlog</filename> will be
included, but it will only contain the files necessary for the
backup to work, not the rest of the contents.
</para>
</listitem>
</itemizedlist>
- Owner, group and file mode are set if the underlying filesystem on
+ Owner, group and file mode are set if the underlying file system on
the server supports it.
</para>
<para>
diff --git a/doc/src/sgml/rangetypes.sgml b/doc/src/sgml/rangetypes.sgml
index 87acca19eaf..dcaa4ecf6c9 100644
--- a/doc/src/sgml/rangetypes.sgml
+++ b/doc/src/sgml/rangetypes.sgml
@@ -473,7 +473,7 @@ with existing key (during)=([ 2010-01-01 14:30:00, 2010-01-01 15:30:00 )).
<para>
You can use the <link linkend="btree-gist"><literal>btree_gist</></link>
- extension to define exclusion constraints on plain scalar datatypes, which
+ extension to define exclusion constraints on plain scalar data types, which
can then be combined with range exclusions for maximum flexibility. For
example, after <literal>btree_gist</literal> is installed, the following
constraint will reject overlapping ranges only if the meeting room numbers
diff --git a/doc/src/sgml/ref/psql-ref.sgml b/doc/src/sgml/ref/psql-ref.sgml
index 969548ffd09..54890a1db53 100644
--- a/doc/src/sgml/ref/psql-ref.sgml
+++ b/doc/src/sgml/ref/psql-ref.sgml
@@ -249,7 +249,7 @@ PostgreSQL documentation
<term><option>--no-readline</></term>
<listitem>
<para>
- Do not use readline for line editing and do not use the history.
+ Do not use <application>readline</application> for line editing and do not use the history.
This can be useful to turn off tab expansion when cutting and pasting.
</para>
</listitem>
@@ -289,7 +289,7 @@ PostgreSQL documentation
Specifies printing options, in the style of
<command>\pset</command>. Note that here you
have to separate name and value with an equal sign instead of a
- space. For example, to set the output format to LaTeX, you could write
+ space. For example, to set the output format to <application>LaTeX</application>, you could write
<literal>-P format=latex</literal>.
</para>
</listitem>
@@ -607,7 +607,7 @@ PostgreSQL documentation
$ <userinput>psql "service=myservice sslmode=require"</userinput>
$ <userinput>psql postgresql://dbmaster:5433/mydb?sslmode=require</userinput>
</programlisting>
- This way you can also use LDAP for connection parameter lookup as
+ This way you can also use <acronym>LDAP</acronym> for connection parameter lookup as
described in <xref linkend="libpq-ldap">.
See <xref linkend="libpq-connect"> for more information on all the
available connection options.
@@ -1670,9 +1670,9 @@ Tue Oct 26 21:40:57 CEST 1999
<listitem>
<para>
The <literal>\ir</> command is similar to <literal>\i</>, but resolves
- relative pathnames differently. When executing in interactive mode,
+ relative file names differently. When executing in interactive mode,
the two commands behave identically. However, when invoked from a
- script, <literal>\ir</literal> interprets pathnames relative to the
+ script, <literal>\ir</literal> interprets file names relative to the
directory in which the script is located, rather than the current
working directory.
</para>
@@ -2001,7 +2001,7 @@ lo_import 152801
formats put out tables that are intended to
be included in documents using the respective mark-up
language. They are not complete documents! (This might not be
- so dramatic in <acronym>HTML</acronym>, but in LaTeX you must
+ so dramatic in <acronym>HTML</acronym>, but in <application>LaTeX</application> you must
have a complete document wrapper.)
</para>
</listitem>
@@ -3031,7 +3031,7 @@ testdb=&gt; <userinput>\set content `cat my_file.txt`</userinput>
testdb=&gt; <userinput>INSERT INTO my_table VALUES (:'content');</userinput>
</programlisting>
(Note that this still won't work if <filename>my_file.txt</filename> contains NUL bytes.
- psql does not support embedded NUL bytes in variable values.)
+ <application>psql</application> does not support embedded NUL bytes in variable values.)
</para>
<para>
@@ -3370,7 +3370,7 @@ PSQL_EDITOR_LINENUMBER_ARG='--line '
<listitem>
<para>
- Alternative location for the command history file. Tilde ("~") expansion is performed.
+ Alternative location for the command history file. Tilde (<literal>~</literal>) expansion is performed.
</para>
</listitem>
</varlistentry>
@@ -3380,7 +3380,7 @@ PSQL_EDITOR_LINENUMBER_ARG='--line '
<listitem>
<para>
- Alternative location of the user's .psqlrc file. Tilde ("~") expansion is performed.
+ Alternative location of the user's <filename>.psqlrc</filename> file. Tilde (<literal>~</literal>) expansion is performed.
</para>
</listitem>
</varlistentry>
@@ -3445,7 +3445,7 @@ PSQL_EDITOR_LINENUMBER_ARG='--line '
<listitem>
<para>
Both the system-wide <filename>psqlrc</filename> file and the user's
- <filename>~/.psqlrc</filename> file can be made psql-version-specific
+ <filename>~/.psqlrc</filename> file can be made <application>psql</application>-version-specific
by appending a dash and the <productname>PostgreSQL</productname>
major or minor <application>psql</application> release number,
for example <filename>~/.psqlrc-9.2</filename> or
diff --git a/doc/src/sgml/rules.sgml b/doc/src/sgml/rules.sgml
index 59a32a8e18b..cc02ada7c71 100644
--- a/doc/src/sgml/rules.sgml
+++ b/doc/src/sgml/rules.sgml
@@ -1892,7 +1892,7 @@ CREATE VIEW phone_number WITH (security_barrier) AS
<para>
The query planner has more flexibility when dealing with functions that
- have no side effects. Such functions are referred to as LEAKPROOF, and
+ have no side effects. Such functions are referred to as <literal>LEAKPROOF</literal>, and
include many simple, commonly used operators, such as many equality
operators. The query planner can safely allow such functions to be evaluated
at any point in the query execution process, since invoking them on rows
@@ -1910,11 +1910,11 @@ CREATE VIEW phone_number WITH (security_barrier) AS
in the limited sense that the contents of the invisible tuples will not be
passed to possibly-insecure functions. The user may well have other means
of making inferences about the unseen data; for example, they can see the
- query plan using <command>EXPLAIN</command>, or measure the runtime of
+ query plan using <command>EXPLAIN</command>, or measure the run time of
queries against the view. A malicious attacker might be able to infer
something about the amount of unseen data, or even gain some information
about the data distribution or most common values (since these things may
- affect the runtime of the plan; or even, since they are also reflected in
+ affect the run time of the plan; or even, since they are also reflected in
the optimizer statistics, the choice of plan). If these types of "covert
channel" attacks are of concern, it is probably unwise to grant any access
to the data at all.
diff --git a/doc/src/sgml/sepgsql.sgml b/doc/src/sgml/sepgsql.sgml
index 730521a5217..ff083a06596 100644
--- a/doc/src/sgml/sepgsql.sgml
+++ b/doc/src/sgml/sepgsql.sgml
@@ -178,7 +178,7 @@ $ for DBNAME in template0 template1 postgres; do
Once built, install this policy package using the
<command>semodule</> command, which loads supplied policy packages
into the kernel. If the package is correctly installed,
- <literal><command>semodule</> -l</> should list sepgsql-regtest as an
+ <literal><command>semodule</> -l</> should list <literal>sepgsql-regtest</literal> as an
available policy package:
</para>
@@ -467,7 +467,7 @@ UPDATE t1 SET x = 2, y = md5sum(y) WHERE z = 100;
<sect3>
<title>Trusted Procedures</title>
<para>
- Trusted procedures are similar to security definer functions or set-uid
+ Trusted procedures are similar to security definer functions or setuid
commands. <productname>SELinux</> provides a feature to allow trusted
code to run using a security label different from that of the client,
generally for the purpose of providing highly controlled access to
diff --git a/doc/src/sgml/spgist.sgml b/doc/src/sgml/spgist.sgml
index fd312cf4368..cec40b8172a 100644
--- a/doc/src/sgml/spgist.sgml
+++ b/doc/src/sgml/spgist.sgml
@@ -102,12 +102,12 @@
<note>
<para>
- The <acronym>SP-GiST</acronym> core code takes care of NULL entries.
+ The <acronym>SP-GiST</acronym> core code takes care of null entries.
Although <acronym>SP-GiST</acronym> indexes do store entries for nulls
in indexed columns, this is hidden from the index operator class code:
no null index entries or search conditions will ever be passed to the
operator class methods. (It is assumed that <acronym>SP-GiST</acronym>
- operators are strict and so cannot succeed for NULL values.) NULLs
+ operators are strict and so cannot succeed for null values.) Null values
are therefore not discussed further here.
</para>
</note>
@@ -136,7 +136,7 @@
<listitem>
<para>
Returns static information about the index implementation, including
- the datatype OIDs of the prefix and node label data types.
+ the data type OIDs of the prefix and node label data types.
</para>
<para>
The <acronym>SQL</> declaration of the function must look like this:
@@ -163,7 +163,7 @@ typedef struct spgConfigOut
</programlisting>
<structfield>attType</> is passed in order to support polymorphic
- index operator classes; for ordinary fixed-data-type opclasses, it
+ index operator classes; for ordinary fixed-data-type operator classes, it
will always have the same value and so can be ignored.
</para>
@@ -626,7 +626,7 @@ typedef struct spgLeafConsistentOut
<para>
This section covers implementation details and other tricks that are
- useful for implementors of <acronym>SP-GiST</acronym> operator classes to
+ useful for implementers of <acronym>SP-GiST</acronym> operator classes to
know.
</para>
diff --git a/doc/src/sgml/textsearch.sgml b/doc/src/sgml/textsearch.sgml
index 46db103cb8f..978aa545cf1 100644
--- a/doc/src/sgml/textsearch.sgml
+++ b/doc/src/sgml/textsearch.sgml
@@ -2292,8 +2292,8 @@ SELECT ts_lexize('public.simple_dict','The');
word with a synonym. Phrases are not supported (use the thesaurus
template (<xref linkend="textsearch-thesaurus">) for that). A synonym
dictionary can be used to overcome linguistic problems, for example, to
- prevent an English stemmer dictionary from reducing the word 'Paris' to
- 'pari'. It is enough to have a <literal>Paris paris</literal> line in the
+ prevent an English stemmer dictionary from reducing the word <quote>Paris</quote> to
+ <quote>pari</quote>. It is enough to have a <literal>Paris paris</literal> line in the
synonym dictionary and put it before the <literal>english_stem</>
dictionary. For example:
diff --git a/doc/src/sgml/xfunc.sgml b/doc/src/sgml/xfunc.sgml
index 58df90e30fe..e2b10703ee9 100644
--- a/doc/src/sgml/xfunc.sgml
+++ b/doc/src/sgml/xfunc.sgml
@@ -1768,7 +1768,7 @@ typedef struct
Finally, all variable-length types must also be passed
by reference. All variable-length types must begin
with an opaque length field of exactly 4 bytes, which will be set
- by SET_VARSIZE; never set this field directly! All data to
+ by <symbol>SET_VARSIZE</symbol>; never set this field directly! All data to
be stored within that type must be located in the memory
immediately following that length field. The
length field contains the total length of the structure,