database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-07-30 11:03:19 +03:00
Code Activity

Fix some typos, grammar and style in docs and comments

Browse Source 
The portions fixing the documentation are backpatched where needed.

Author: Justin Pryzby
Discussion: https://postgr.es/m/20210210235557.GQ20012@telsasoft.com
backpatch-through: 9.6
This commit is contained in:
Michael Paquier
2021-02-24 16:13:17 +09:00
parent 8ec8fe0f31
commit bcf2667bf6
30 changed files with 73 additions and 75 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
doc/src/sgml/charset.sgml
View File

@ -619,7 +619,7 @@ SELECT * FROM test1 ORDER BY a || b COLLATE "fr_FR";
name such as <literal>de_DE</literal> can be considered unique
within a given database even though it would not be unique globally.
Use of the stripped collation names is recommended, since it will
make one less thing you need to change if you decide to change to
make one fewer thing you need to change if you decide to change to
another database encoding. Note however that the <literal>default</literal>,
<literal>C</literal>, and <literal>POSIX</literal> collations can be used regardless of
the database encoding.

2
doc/src/sgml/extend.sgml
View File

@ -448,7 +448,7 @@
of <type>anycompatible</type> and <type>anycompatiblenonarray</type>
inputs, the array element types of <type>anycompatiblearray</type>
inputs, the range subtypes of <type>anycompatiblerange</type> inputs,
and the multirange subtypes of <type>anycompatiablemultirange</type>
and the multirange subtypes of <type>anycompatiblemultirange</type>
inputs. If <type>anycompatiblenonarray</type> is present then the
common type is required to be a non-array type. Once a common type is
identified, arguments in <type>anycompatible</type>

9
doc/src/sgml/fdwhandler.sgml
View File

@ -626,7 +626,7 @@ ExecForeignBatchInsert(EState *estate,
Insert multiple tuples in bulk into the foreign table.
The parameters are the same for <function>ExecForeignInsert</function>
except <literal>slots</literal> and <literal>planSlots</literal> contain
multiple tuples and <literal>*numSlots></literal> specifies the number of
multiple tuples and <literal>*numSlots</literal> specifies the number of
tuples in those arrays.
</para>
@ -655,7 +655,7 @@ ExecForeignBatchInsert(EState *estate,
<literal>NULL</literal>, attempts to insert into the foreign table will
use <function>ExecForeignInsert</function>.
This function is not used if the <command>INSERT</command> has the
<literal>RETURNING></literal> clause.
<literal>RETURNING</literal> clause.
</para>
<para>
@ -672,9 +672,8 @@ GetForeignModifyBatchSize(ResultRelInfo *rinfo);
Report the maximum number of tuples that a single
<function>ExecForeignBatchInsert</function> call can handle for
the specified foreign table. That is, The executor passes at most
the number of tuples that this function returns to
<function>ExecForeignBatchInsert</function>.
the specified foreign table. The executor passes at most
the given number of tuples to <function>ExecForeignBatchInsert</function>.
<literal>rinfo</literal> is the <structname>ResultRelInfo</structname> struct describing
the target foreign table.
The FDW is expected to provide a foreign server and/or foreign

43
doc/src/sgml/logicaldecoding.sgml
View File

@ -791,9 +791,9 @@ typedef void (*LogicalDecodeMessageCB) (struct LogicalDecodingContext *ctx,
<para>
The optional <function>filter_prepare_cb</function> callback
is called to determine whether data that is part of the current
two-phase commit transaction should be considered for decode
at this prepare stage or as a regular one-phase transaction at
<command>COMMIT PREPARED</command> time later. To signal that
two-phase commit transaction should be considered for decoding
at this prepare stage or later as a regular one-phase transaction at
<command>COMMIT PREPARED</command> time. To signal that
decoding should be skipped, return <literal>true</literal>;
<literal>false</literal> otherwise. When the callback is not
defined, <literal>false</literal> is assumed (i.e. nothing is
@ -820,12 +820,12 @@ typedef bool (*LogicalDecodeFilterPrepareCB) (struct LogicalDecodingContext *ctx
The required <function>begin_prepare_cb</function> callback is called
whenever the start of a prepared transaction has been decoded. The
<parameter>gid</parameter> field, which is part of the
<parameter>txn</parameter> parameter can be used in this callback to
check if the plugin has already received this prepare in which case it
can skip the remaining changes of the transaction. This can only happen
if the user restarts the decoding after receiving the prepare for a
transaction but before receiving the commit prepared say because of some
error.
<parameter>txn</parameter> parameter, can be used in this callback to
check if the plugin has already received this <command>PREPARE</command>
in which case it can skip the remaining changes of the transaction.
This can only happen if the user restarts the decoding after receiving
the <command>PREPARE</command> for a transaction but before receiving
the <command>COMMIT PREPARED</command>, say because of some error.
<programlisting>
typedef void (*LogicalDecodeBeginPrepareCB) (struct LogicalDecodingContext *ctx,
ReorderBufferTXN *txn);
@ -842,7 +842,7 @@ typedef bool (*LogicalDecodeFilterPrepareCB) (struct LogicalDecodingContext *ctx
decoded. The <function>change_cb</function> callback for all modified
rows will have been called before this, if there have been any modified
rows. The <parameter>gid</parameter> field, which is part of the
<parameter>txn</parameter> parameter can be used in this callback.
<parameter>txn</parameter> parameter, can be used in this callback.
<programlisting>
typedef void (*LogicalDecodePrepareCB) (struct LogicalDecodingContext *ctx,
ReorderBufferTXN *txn,
@ -856,9 +856,9 @@ typedef bool (*LogicalDecodeFilterPrepareCB) (struct LogicalDecodingContext *ctx
<para>
The required <function>commit_prepared_cb</function> callback is called
whenever a transaction commit prepared has been decoded. The
<parameter>gid</parameter> field, which is part of the
<parameter>txn</parameter> parameter can be used in this callback.
whenever a transaction <command>COMMIT PREPARED</command> has been decoded.
The <parameter>gid</parameter> field, which is part of the
<parameter>txn</parameter> parameter, can be used in this callback.
<programlisting>
typedef void (*LogicalDecodeCommitPreparedCB) (struct LogicalDecodingContext *ctx,
ReorderBufferTXN *txn,
@ -872,15 +872,15 @@ typedef bool (*LogicalDecodeFilterPrepareCB) (struct LogicalDecodingContext *ctx
<para>
The required <function>rollback_prepared_cb</function> callback is called
whenever a transaction rollback prepared has been decoded. The
<parameter>gid</parameter> field, which is part of the
<parameter>txn</parameter> parameter can be used in this callback. The
whenever a transaction <command>ROLLBACK PREPARED</command> has been
decoded. The <parameter>gid</parameter> field, which is part of the
<parameter>txn</parameter> parameter, can be used in this callback. The
parameters <parameter>prepare_end_lsn</parameter> and
<parameter>prepare_time</parameter> can be used to check if the plugin
has received this prepare transaction in which case it can apply the
rollback, otherwise, it can skip the rollback operation. The
has received this <command>PREPARE TRANSACTION</command> in which case
it can apply the rollback, otherwise, it can skip the rollback operation. The
<parameter>gid</parameter> alone is not sufficient because the downstream
node can have prepared transaction with same identifier.
node can have a prepared transaction with same identifier.
<programlisting>
typedef void (*LogicalDecodeRollbackPreparedCB) (struct LogicalDecodingContext *ctx,
ReorderBufferTXN *txn,
@ -1122,7 +1122,8 @@ OutputPluginWrite(ctx, true);
the <function>stream_commit_cb</function> callback
(or possibly aborted using the <function>stream_abort_cb</function> callback).
If two-phase commits are supported, the transaction can be prepared using the
<function>stream_prepare_cb</function> callback, commit prepared using the
<function>stream_prepare_cb</function> callback,
<command>COMMIT PREPARED</command> using the
<function>commit_prepared_cb</function> callback or aborted using the
<function>rollback_prepared_cb</function>.
</para>
@ -1214,7 +1215,7 @@ stream_commit_cb(...); &lt;-- commit of the streamed transaction
</para>
<para>
When a prepared transaction is rollbacked using the
When a prepared transaction is rolled back using the
<command>ROLLBACK PREPARED</command>, then the
<function>rollback_prepared_cb</function> callback is invoked and when the
prepared transaction is committed using <command>COMMIT PREPARED</command>,

2
doc/src/sgml/pageinspect.sgml
View File

@ -211,7 +211,7 @@ test=# SELECT tuple_data_split('pg_class'::regclass, t_data, t_infomask, t_infom
</para>
<para>
If <parameter>do_detoast</parameter> is <literal>true</literal>,
attribute that will be detoasted as needed. Default value is
attributes will be detoasted as needed. Default value is
<literal>false</literal>.
</para>
</listitem>

20
doc/src/sgml/postgres-fdw.sgml
View File

@ -553,7 +553,7 @@ postgres=# SELECT postgres_fdw_disconnect('loopback1');
<para>
This function discards all the open connections that are established by
<filename>postgres_fdw</filename> from the local session to
the foreign servers. If the connections are used in the current local
foreign servers. If the connections are used in the current local
transaction, they are not disconnected and warning messages are reported.
This function returns <literal>true</literal> if it disconnects
at least one connection, otherwise <literal>false</literal>.
@ -585,22 +585,22 @@ postgres=# SELECT postgres_fdw_disconnect_all();
<para>
When changing the definition of or removing a foreign server or
a user mapping, the corresponding connections are closed.
But note that if the connections are used in the current local transaction
at that moment, they are kept until the end of the transaction.
Closed connections will be established again when they are necessary
by subsequent queries using a foreign table.
a user mapping, the associated connections are closed.
But note that if any connections are in use in the current local transaction,
they are kept until the end of the transaction.
Closed connections will be re-established when they are necessary
by future queries using a foreign table.
</para>
<para>
Once a connection to a foreign server has been established,
it's usually kept until the local or the corresponding remote
it's usually kept until the local or corresponding remote
session exits. To disconnect a connection explicitly,
<function>postgres_fdw_disconnect</function> and
<function>postgres_fdw_disconnect_all</function> functions
need to be used. For example, these are useful when closing
the connections that are no longer necessary and then preventing them
from consuming the foreign server connections capacity too much.
may be used. For example, these are useful to close
connections that are no longer necessary, thereby releasing
connections on the foreign server.
</para>
</sect2>

4
doc/src/sgml/protocol.sgml
View File

@ -6928,8 +6928,8 @@ Delete
</term>
<listitem>
<para>
Identifies the following TupleData message as a old tuple.
This field is present if the table in which the delete has
Identifies the following TupleData message as an old tuple.
This field is present if the table in which the delete
happened has REPLICA IDENTITY set to FULL.
</para>
</listitem>

2
doc/src/sgml/ref/alter_subscription.sgml
View File

@ -56,7 +56,7 @@ ALTER SUBSCRIPTION <replaceable class="parameter">name</replaceable> RENAME TO <
allocated for the subscription on the remote host are released. If due to
network breakdown or some other error, <productname>PostgreSQL</productname>
is unable to remove the slots, an ERROR will be reported. To proceed in this
situation, either the user need to retry the operation or disassociate the
situation, the user either needs to retry the operation or disassociate the
slot from the subscription and drop the subscription as explained in
<xref linkend="sql-dropsubscription"/>.
</para>

2
doc/src/sgml/ref/create_type.sgml
View File

@ -867,7 +867,7 @@ CREATE TYPE <replaceable class="parameter">name</replaceable>
Before <productname>PostgreSQL</productname> version 8.3, the name of
a generated array type was always exactly the element type's name with one
underscore character (<literal>_</literal>) prepended. (Type names were
therefore restricted in length to one less character than other names.)
therefore restricted in length to one fewer character than other names.)
While this is still usually the case, the array type name may vary from
this in case of maximum-length names or collisions with user type names
that begin with underscore. Writing code that depends on this convention

2
doc/src/sgml/ref/drop_index.sgml
View File

@ -45,7 +45,7 @@ DROP INDEX [ CONCURRENTLY ] [ IF EXISTS ] <replaceable class="parameter">name</r
<para>
Drop the index without locking out concurrent selects, inserts, updates,
and deletes on the index's table. A normal <command>DROP INDEX</command>
acquires exclusive lock on the table, blocking other accesses until the
acquires an exclusive lock on the table, blocking other accesses until the
index drop can be completed. With this option, the command instead
waits until conflicting transactions have completed.
</para>

2
doc/src/sgml/rules.sgml
View File

@ -1266,7 +1266,7 @@ CREATE [ OR REPLACE ] RULE <replaceable class="parameter">name</replaceable> AS
<para>
The query trees generated from rule actions are thrown into the
rewrite system again, and maybe more rules get applied resulting
in more or less query trees.
in additional or fewer query trees.
So a rule's actions must have either a different
command type or a different result relation than the rule itself is
on, otherwise this recursive process will end up in an infinite loop.

18
doc/src/sgml/wal.sgml
View File

@ -237,19 +237,19 @@
</indexterm>
<para>
Data pages are not checksum protected by default, but this can optionally be
enabled for a cluster. When enabled, each data page will be assigned a
checksum that is updated when the page is written and verified every time
the page is read. Only data pages are protected by checksums, internal data
By default, data pages are not protected by checksums, but this can optionally be
enabled for a cluster. When enabled, each data page will be ASSIGNED a
checksum that is updated when the page is written and verified each time
the page is read. Only data pages are protected by checksums; internal data
structures and temporary files are not.
</para>
<para>
Checksums are normally enabled when the cluster is initialized using <link
Checksums verification is normally ENABLED when the cluster is initialized using <link
linkend="app-initdb-data-checksums"><application>initdb</application></link>.
They can also be enabled or disabled at a later time as an offline
operation. Data checksums are enabled or disabled at the full cluster
level, and cannot be specified individually for databases or tables.
level, and cannot be specified for individual databases or tables.
</para>
<para>
@ -260,9 +260,9 @@
</para>
<para>
When attempting to recover from corrupt data it may be necessary to bypass
the checksum protection in order to recover data. To do this, temporarily
set the configuration parameter <xref linkend="guc-ignore-checksum-failure" />.
When attempting to recover from corrupt data, it may be necessary to bypass
the checksum protection. To do this, temporarily set the configuration
parameter <xref linkend="guc-ignore-checksum-failure" />.
</para>
<sect2 id="checksums-offline-enable-disable">