mirror of
https://github.com/postgres/postgres.git
synced 2025-12-22 17:42:17 +03:00
Documentation spell checking and markup improvements
This commit is contained in:
@@ -121,8 +121,8 @@ COPY { <replaceable class="parameter">table_name</replaceable> [ ( <replaceable
|
||||
<term><replaceable class="parameter">filename</replaceable></term>
|
||||
<listitem>
|
||||
<para>
|
||||
The path name of the input or output file. An input filename can be
|
||||
an absolute or relative path, but an output filename must be an absolute
|
||||
The path name of the input or output file. An input file name can be
|
||||
an absolute or relative path, but an output file name must be an absolute
|
||||
path. Windows users might need to use an <literal>E''</> string and
|
||||
double any backslashes used in the path name.
|
||||
</para>
|
||||
|
||||
@@ -364,7 +364,7 @@ CREATE [ [ GLOBAL | LOCAL ] { TEMPORARY | TEMP } | UNLOGGED ] TABLE [ IF NOT EXI
|
||||
constraints copied by <literal>LIKE</> are not merged with similarly
|
||||
named columns and constraints.
|
||||
If the same name is specified explicitly or in another
|
||||
<literal>LIKE</literal> clause, an error is signalled.
|
||||
<literal>LIKE</literal> clause, an error is signaled.
|
||||
</para>
|
||||
<para>
|
||||
The <literal>LIKE</literal> clause can also be used to copy columns from
|
||||
|
||||
@@ -136,7 +136,7 @@ CREATE TYPE <replaceable class="parameter">name</replaceable>
|
||||
be any type with an associated b-tree operator class (to determine the
|
||||
ordering of values for the range type). Normally the subtype's default
|
||||
b-tree operator class is used to determine ordering; to use a non-default
|
||||
opclass, specify its name with <replaceable
|
||||
operator class, specify its name with <replaceable
|
||||
class="parameter">subtype_opclass</replaceable>. If the subtype is
|
||||
collatable, and you want to use a non-default collation in the range's
|
||||
ordering, specify the desired collation with the <replaceable
|
||||
|
||||
@@ -75,7 +75,7 @@ EXPLAIN [ ANALYZE ] [ VERBOSE ] <replaceable class="parameter">statement</replac
|
||||
|
||||
<para>
|
||||
The <literal>ANALYZE</literal> option causes the statement to be actually
|
||||
executed, not only planned. Then actual runtime statistics are added to
|
||||
executed, not only planned. Then actual run time statistics are added to
|
||||
the display, including the total elapsed time expended within each plan
|
||||
node (in milliseconds) and the total number of rows it actually returned.
|
||||
This is useful for seeing whether the planner's estimates
|
||||
|
||||
@@ -183,7 +183,7 @@ LOCK [ TABLE ] [ ONLY ] <replaceable class="PARAMETER">name</replaceable> [ * ]
|
||||
the mode names involving <literal>ROW</> are all misnomers. These
|
||||
mode names should generally be read as indicating the intention of
|
||||
the user to acquire row-level locks within the locked table. Also,
|
||||
<literal>ROW EXCLUSIVE</> mode is a sharable table lock. Keep in
|
||||
<literal>ROW EXCLUSIVE</> mode is a shareable table lock. Keep in
|
||||
mind that all the lock modes have identical semantics so far as
|
||||
<command>LOCK TABLE</> is concerned, differing only in the rules
|
||||
about which modes conflict with which. For information on how to
|
||||
|
||||
@@ -194,7 +194,7 @@ PostgreSQL documentation
|
||||
<listitem>
|
||||
|
||||
<para>
|
||||
Write a minimal recovery.conf in the output directory (or into
|
||||
Write a minimal <filename>recovery.conf</filename> in the output directory (or into
|
||||
the base archive file when using tar format) to ease setting
|
||||
up a standby server.
|
||||
</para>
|
||||
|
||||
@@ -323,10 +323,10 @@ PostgreSQL documentation
|
||||
<para>
|
||||
For a consistent backup, the database server needs to support synchronized snapshots,
|
||||
a feature that was introduced in <productname>PostgreSQL</productname> 9.2. With this
|
||||
feature, database clients can ensure they see the same dataset even though they use
|
||||
feature, database clients can ensure they see the same data set even though they use
|
||||
different connections. <command>pg_dump -j</command> uses multiple database
|
||||
connections; it connects to the database once with the master process and
|
||||
once again for each worker job. Without the sychronized snapshot feature, the
|
||||
once again for each worker job. Without the synchronized snapshot feature, the
|
||||
different worker jobs wouldn't be guaranteed to see the same data in each connection,
|
||||
which could lead to an inconsistent backup.
|
||||
</para>
|
||||
|
||||
Reference in New Issue
Block a user