Skip to content

Commit 103ef20

Browse files
peterepetere
committed
doc: Spell checking
1 parent 87efbc2 commit 103ef20

36 files changed

+119
-119
lines changed

‎doc/src/sgml/backup.sgml

+2-2
Original file line numberDiff line numberDiff line change
@@ -40,7 +40,7 @@ pg_dump <replaceable class="parameter">dbname</replaceable> &gt; <replaceable cl
4040
As you see, <application>pg_dump</> writes its result to the
4141
standard output. We will see below how this can be useful.
4242
While the above command creates a text file, <application>pg_dump</>
43-
can create files in other formats that allow for parallism and more
43+
can create files in other formats that allow for parallelism and more
4444
fine-grained control of object restoration.
4545
</para>
4646

@@ -221,7 +221,7 @@ psql -f <replaceable class="parameter">infile</replaceable> postgres
221221
roles, tablespaces, and empty databases, then invoking
222222
<application>pg_dump</> for each database. This means that while
223223
each database will be internally consistent, the snapshots of
224-
different databases are not sychronized.
224+
different databases are not synchronized.
225225
</para>
226226

227227
<para>

‎doc/src/sgml/brin.sgml

+3-3
Original file line numberDiff line numberDiff line change
@@ -532,7 +532,7 @@ typedef struct BrinOpcInfo
532532
The core distribution includes support for two types of operator classes:
533533
minmax and inclusion. Operator class definitions using them are shipped for
534534
in-core data types as appropriate. Additional operator classes can be
535-
defined by the user for other datatypes using equivalent definitions,
535+
defined by the user for other data types using equivalent definitions,
536536
without having to write any source code; appropriate catalog entries being
537537
declared is enough. Note that assumptions about the semantics of operator
538538
strategies are embedded in the support procedures's source code.
@@ -547,8 +547,8 @@ typedef struct BrinOpcInfo
547547
</para>
548548

549549
<para>
550-
To write an operator class for a datatype that implements a totally
551-
ordered set, it is possible to use the Minmax support procedures
550+
To write an operator class for a data type that implements a totally
551+
ordered set, it is possible to use the minmax support procedures
552552
alongside the corresponding operators, as shown in
553553
<xref linkend="brin-extensibility-minmax-table">.
554554
All operator class members (procedures and operators) are mandatory.

‎doc/src/sgml/catalogs.sgml

+1-1
Original file line numberDiff line numberDiff line change
@@ -7946,7 +7946,7 @@
79467946
<row>
79477947
<entry><structfield>sourcefile</structfield></entry>
79487948
<entry><structfield>text</structfield></entry>
7949-
<entry>Full pathname of the configuration file</entry>
7949+
<entry>Full path name of the configuration file</entry>
79507950
</row>
79517951
<row>
79527952
<entry><structfield>sourceline</structfield></entry>

‎doc/src/sgml/client-auth.sgml

+9-9
Original file line numberDiff line numberDiff line change
@@ -958,11 +958,11 @@ omicron bryanh guest1
958958
<productname>PostgreSQL</> also supports a parameter to strip the realm from
959959
the principal. This method is supported for backwards compatibility and is
960960
strongly discouraged as it is then impossible to distinguish different users
961-
with the same username but coming from different realms. To enable this,
961+
with the same user name but coming from different realms. To enable this,
962962
set <literal>include_realm</> to 0. For simple single-realm
963963
installations, <literal>include_realm</> combined with the
964964
<literal>krb_realm</> parameter (which checks that the realm provided
965-
matches exactly what is in the krb_realm parameter) would be a secure but
965+
matches exactly what is in the <literal>krb_realm</literal> parameter) would be a secure but
966966
less capable option compared to specifying an explicit mapping in
967967
<filename>pg_ident.conf</>.
968968
</para>
@@ -1009,8 +1009,8 @@ omicron bryanh guest1
10091009
If set to 0, the realm name from the authenticated user principal is
10101010
stripped off before being passed through the user name mapping
10111011
(<xref linkend="auth-username-maps">). This is discouraged and is
1012-
primairly available for backwards compatibility as it is not secure
1013-
in multi-realm environments unless krb_realm is also used. Users
1012+
primarily available for backwards compatibility as it is not secure
1013+
in multi-realm environments unless <literal>krb_realm</literal> is also used. Users
10141014
are recommended to leave include_realm set to the default (1) and to
10151015
provide an explicit mapping in <filename>pg_ident.conf</>.
10161016
</para>
@@ -1030,7 +1030,7 @@ omicron bryanh guest1
10301030
<literal>username/hostbased@EXAMPLE.COM</literal>, respectively),
10311031
unless <literal>include_realm</literal> has been set to 0, in which case
10321032
<literal>username</literal> (or <literal>username/hostbased</literal>)
1033-
is what is seen as the system username when mapping.
1033+
is what is seen as the system user name when mapping.
10341034
</para>
10351035
</listitem>
10361036
</varlistentry>
@@ -1088,8 +1088,8 @@ omicron bryanh guest1
10881088
If set to 0, the realm name from the authenticated user principal is
10891089
stripped off before being passed through the user name mapping
10901090
(<xref linkend="auth-username-maps">). This is discouraged and is
1091-
primairly available for backwards compatibility as it is not secure
1092-
in multi-realm environments unless krb_realm is also used. Users
1091+
primarily available for backwards compatibility as it is not secure
1092+
in multi-realm environments unless <literal>krb_realm</literal> is also used. Users
10931093
are recommended to leave include_realm set to the default (1) and to
10941094
provide an explicit mapping in <filename>pg_ident.conf</>.
10951095
</para>
@@ -1109,7 +1109,7 @@ omicron bryanh guest1
11091109
<literal>username/hostbased@EXAMPLE.COM</literal>, respectively),
11101110
unless <literal>include_realm</literal> has been set to 0, in which case
11111111
<literal>username</literal> (or <literal>username/hostbased</literal>)
1112-
is what is seen as the system username when mapping.
1112+
is what is seen as the system user name when mapping.
11131113
</para>
11141114
</listitem>
11151115
</varlistentry>
@@ -1292,7 +1292,7 @@ omicron bryanh guest1
12921292
this search, the server disconnects and re-binds to the directory as
12931293
this user, using the password specified by the client, to verify that the
12941294
login is correct. This mode is the same as that used by LDAP authentication
1295-
schemes in other software, such as Apache mod_authnz_ldap and pam_ldap.
1295+
schemes in other software, such as Apache <literal>mod_authnz_ldap</literal> and <literal>pam_ldap</literal>.
12961296
This method allows for significantly more flexibility
12971297
in where the user objects are located in the directory, but will cause
12981298
two separate connections to the LDAP server to be made.

‎doc/src/sgml/config.sgml

+3-3
Original file line numberDiff line numberDiff line change
@@ -1902,7 +1902,7 @@ include_dir 'conf.d'
19021902

19031903
<para>
19041904
The default is 1 on supported systems, otherwise 0. This value can
1905-
be overriden for tables in a particular tablespace by setting the
1905+
be overridden for tables in a particular tablespace by setting the
19061906
tablespace parameter of the same name (see
19071907
<xref linkend="sql-altertablespace">).
19081908
</para>
@@ -1993,7 +1993,7 @@ include_dir 'conf.d'
19931993
<para>
19941994
In <literal>logical</> level, the same information is logged as
19951995
with <literal>hot_standby</>, plus information needed to allow
1996-
extracting logical changesets from the WAL. Using a level of
1996+
extracting logical change sets from the WAL. Using a level of
19971997
<literal>logical</> will increase the WAL volume, particularly if many
19981998
tables are configured for <literal>REPLICA IDENTITY FULL</literal> and
19991999
many <command>UPDATE</> and <command>DELETE</> statements are
@@ -3909,7 +3909,7 @@ local0.* /var/log/postgresql
39093909
listed in the Open Group's <ulink
39103910
url="http://pubs.opengroup.org/onlinepubs/009695399/functions/strftime.html">strftime
39113911
</ulink> specification.
3912-
Note that the system's <systemitem>strftime</systemitem> is not used
3912+
Note that the system's <function>strftime</function> is not used
39133913
directly, so platform-specific (nonstandard) extensions do not work.
39143914
The default is <literal>postgresql-%Y-%m-%d_%H%M%S.log</literal>.
39153915
</para>

‎doc/src/sgml/custom-scan.sgml

+6-6
Original file line numberDiff line numberDiff line change
@@ -70,7 +70,7 @@ typedef struct CustomPath
7070
<para>
7171
<structfield>path</> must be initialized as for any other path, including
7272
the row-count estimate, start and total cost, and sort ordering provided
73-
by this path. <structfield>flags</> is a bitmask, which should include
73+
by this path. <structfield>flags</> is a bit mask, which should include
7474
<literal>CUSTOMPATH_SUPPORT_BACKWARD_SCAN</> if the custom path can support
7575
a backward scan and <literal>CUSTOMPATH_SUPPORT_MARK_RESTORE</> if it
7676
can support mark and restore. Both capabilities are optional.
@@ -163,7 +163,7 @@ typedef struct CustomScan
163163
<para>
164164
<structfield>scan</> must be initialized as for any other scan, including
165165
estimated costs, target lists, qualifications, and so on.
166-
<structfield>flags</> is a bitmask with the same meaning as in
166+
<structfield>flags</> is a bit mask with the same meaning as in
167167
<structname>CustomPath</>.
168168
<structfield>custom_plans</> can be used to store child
169169
<structname>Plan</> nodes.
@@ -174,12 +174,12 @@ typedef struct CustomScan
174174
that is only used by the custom scan provider itself.
175175
<structfield>custom_scan_tlist</> can be NIL when scanning a base
176176
relation, indicating that the custom scan returns scan tuples that match
177-
the base relation's rowtype. Otherwise it is a targetlist describing
177+
the base relation's row type. Otherwise it is a target list describing
178178
the actual scan tuples. <structfield>custom_scan_tlist</> must be
179179
provided for joins, and could be provided for scans if the custom scan
180180
provider can compute some non-Var expressions.
181181
<structfield>custom_relids</> is set by the core code to the set of
182-
relations (rangetable indexes) that this scan node handles; except when
182+
relations (range table indexes) that this scan node handles; except when
183183
this scan is replacing a join, it will have only one member.
184184
<structfield>methods</> must point to a (usually statically allocated)
185185
object implementing the required custom scan methods, which are further
@@ -251,10 +251,10 @@ typedef struct CustomScanState
251251
</para>
252252

253253
<para>
254-
<structfield>ss</> is initialized as for any other scanstate,
254+
<structfield>ss</> is initialized as for any other scan state,
255255
except that if the scan is for a join rather than a base relation,
256256
<literal>ss.ss_currentRelation</> is left NULL.
257-
<structfield>flags</> is a bitmask with the same meaning as in
257+
<structfield>flags</> is a bit mask with the same meaning as in
258258
<structname>CustomPath</> and <structname>CustomScan</>.
259259
<structfield>methods</> must point to a (usually statically allocated)
260260
object implementing the required custom scan state methods, which are

‎doc/src/sgml/ddl.sgml

+4-4
Original file line numberDiff line numberDiff line change
@@ -545,7 +545,7 @@ CREATE TABLE products (
545545
</para>
546546

547547
<para>
548-
Adding a unique constraint will automatically create a unique btree
548+
Adding a unique constraint will automatically create a unique B-tree
549549
index on the column or group of columns used in the constraint.
550550
A uniqueness constraint on only some rows can be enforced by creating
551551
a <link linkend="indexes-partial">partial index</link>.
@@ -630,7 +630,7 @@ CREATE TABLE example (
630630
</para>
631631

632632
<para>
633-
Adding a primary key will automatically create a unique btree index
633+
Adding a primary key will automatically create a unique B-tree index
634634
on the column or group of columns used in the primary key.
635635
</para>
636636

@@ -1559,7 +1559,7 @@ REVOKE ALL ON accounts FROM PUBLIC;
15591559
<para>
15601560
To specify which rows are visible and what rows can be added to the
15611561
table with row level security, an expression is required which returns
1562-
a boolean result. This expression will be evaluated for each row prior
1562+
a Boolean result. This expression will be evaluated for each row prior
15631563
to other conditionals or functions which are part of the query. The
15641564
one exception to this rule are <literal>leakproof</literal> functions,
15651565
which are guaranteed to not leak information. Two expressions may be
@@ -1676,7 +1676,7 @@ CREATE POLICY user_policy ON users
16761676

16771677
<para>
16781678
Below is a larger example of how this feature can be used in
1679-
production environments, based on a unix password file.
1679+
production environments, based on a Unix password file.
16801680
</para>
16811681

16821682
<programlisting>

‎doc/src/sgml/fdwhandler.sgml

+5-5
Original file line numberDiff line numberDiff line change
@@ -239,7 +239,7 @@ IterateForeignScan (ForeignScanState *node);
239239

240240
<para>
241241
The rows returned must match the <structfield>fdw_scan_tlist</> target
242-
list if one was supplied, otherwise they must match the rowtype of the
242+
list if one was supplied, otherwise they must match the row type of the
243243
foreign table being scanned. If you choose to optimize away fetching
244244
columns that are not needed, you should insert nulls in those column
245245
positions, or else generate a <structfield>fdw_scan_tlist</> list with
@@ -333,7 +333,7 @@ GetForeignJoinPaths (PlannerInfo *root,
333333
remote join cannot be found from the system catalogs, the FDW must
334334
fill <structfield>fdw_scan_tlist</> with an appropriate list
335335
of <structfield>TargetEntry</> nodes, representing the set of columns
336-
it will supply at runtime in the tuples it returns.
336+
it will supply at run time in the tuples it returns.
337337
</para>
338338

339339
<para>
@@ -752,7 +752,7 @@ RefetchForeignRow (EState *estate,
752752
for the row to be re-fetched. Although the <literal>rowid</> value is
753753
passed as a <type>Datum</>, it can currently only be a <type>tid</>. The
754754
function API is chosen in hopes that it may be possible to allow other
755-
datatypes for row IDs in future.
755+
data types for row IDs in future.
756756
</para>
757757

758758
<para>
@@ -1140,8 +1140,8 @@ GetForeignServerByName(const char *name, bool missing_ok);
11401140
is <structfield>fdw_scan_tlist</>, which describes the tuples returned by
11411141
the FDW for this plan node. For simple foreign table scans this can be
11421142
set to <literal>NIL</>, implying that the returned tuples have the
1143-
rowtype declared for the foreign table. A non-NIL value must be a
1144-
targetlist (list of <structname>TargetEntry</>s) containing Vars and/or
1143+
row type declared for the foreign table. A non-<symbol>NIL</symbol> value must be a
1144+
target list (list of <structname>TargetEntry</>s) containing Vars and/or
11451145
expressions representing the returned columns. This might be used, for
11461146
example, to show that the FDW has omitted some columns that it noticed
11471147
won't be needed for the query. Also, if the FDW can compute expressions

‎doc/src/sgml/func.sgml

+5-5
Original file line numberDiff line numberDiff line change
@@ -10327,7 +10327,7 @@ table2-mapping
1032710327
<row>
1032810328
<entry><literal>||</literal></entry>
1032910329
<entry><type>jsonb</type></entry>
10330-
<entry>Concatentate two jsonb values into a new jsonb value</entry>
10330+
<entry>Concatenate two <type>jsonb</type> values into a new <type>jsonb</type> value</entry>
1033110331
<entry><literal>'["a", "b"]'::jsonb || '["c", "d"]'::jsonb</literal></entry>
1033210332
</row>
1033310333
<row>
@@ -10986,7 +10986,7 @@ table2-mapping
1098610986
If the argument to <literal>json_strip_nulls</> contains duplicate
1098710987
field names in any object, the result could be semantically somewhat
1098810988
different, depending on the order in which they occur. This is not an
10989-
issue for <literal>jsonb_strip_nulls</> since jsonb values never have
10989+
issue for <literal>jsonb_strip_nulls</> since <type>jsonb</type> values never have
1099010990
duplicate object field names.
1099110991
</para>
1099210992
</note>
@@ -13433,7 +13433,7 @@ SELECT xmlagg(x) FROM (SELECT x FROM test ORDER BY y DESC) AS tab;
1343313433
<type>integer</type>
1343413434
</entry>
1343513435
<entry>
13436-
Integer bitmask indicating which arguments are not being included in the current
13436+
Integer bit mask indicating which arguments are not being included in the current
1343713437
grouping set
1343813438
</entry>
1343913439
</row>
@@ -16633,7 +16633,7 @@ SELECT set_config('log_statement_stats', 'off', false);
1663316633
</entry>
1663416634
<entry><type>boolean</type></entry>
1663516635
<entry>Cancel a backend's current query. This is also allowed if the
16636-
calling role is a member of the role whose backend is being cancelled,
16636+
calling role is a member of the role whose backend is being canceled,
1663716637
however only superusers can cancel superuser backends.
1663816638
</entry>
1663916639
</row>
@@ -18600,7 +18600,7 @@ CREATE EVENT TRIGGER test_event_trigger_for_drops
1860018600
<literal><function>pg_event_trigger_table_rewrite_oid()</function></literal>
1860118601
</entry>
1860218602
<entry><type>Oid</type></entry>
18603-
<entry>The Oid of the table about to be rewritten.</entry>
18603+
<entry>The OID of the table about to be rewritten.</entry>
1860418604
</row>
1860518605

1860618606
<row>

‎doc/src/sgml/indices.sgml

+1-1
Original file line numberDiff line numberDiff line change
@@ -343,7 +343,7 @@ SELECT * FROM places ORDER BY location <-> point '(101,456)' LIMIT 10;
343343
BRIN can support many different indexing strategies,
344344
and the particular operators with which a BRIN index can be used
345345
vary depending on the indexing strategy.
346-
For datatypes that have a linear sort order, the indexed data
346+
For data types that have a linear sort order, the indexed data
347347
corresponds to the minimum and maximum values of the
348348
values in the column for each block range,
349349
which support indexed queries using these operators:

‎doc/src/sgml/libpq.sgml

+2-2
Original file line numberDiff line numberDiff line change
@@ -139,7 +139,7 @@ PGconn *PQconnectdbParams(const char * const *keywords,
139139
</para>
140140

141141
<para>
142-
If any parameter is <symbol>NULL</symbol> or an emptry string, the corresponding
142+
If any parameter is <symbol>NULL</symbol> or an empty string, the corresponding
143143
environment variable (see <xref linkend="libpq-envars">) is checked.
144144
If the environment variable is not set either, then the indicated
145145
built-in defaults are used.
@@ -2014,7 +2014,7 @@ void *PQgetssl(const PGconn *conn);
20142014
</para>
20152015

20162016
<para>
2017-
This function is equivalent to PQsslStruct(conn, "OpenSSL"). It should
2017+
This function is equivalent to <literal>PQsslStruct(conn, "OpenSSL")</literal>. It should
20182018
not be used in new applications, because the returned struct is
20192019
specific to OpenSSL and will not be available if another SSL
20202020
implementation is used. To check if a connection uses SSL, call

‎doc/src/sgml/logicaldecoding.sgml

+2-2
Original file line numberDiff line numberDiff line change
@@ -577,7 +577,7 @@ typedef void (*LogicalDecodeChangeCB) (
577577

578578
<para>
579579
The optional <function>filter_by_origin_cb</function> callback
580-
is called to determine wheter data that has been replayed
580+
is called to determine whether data that has been replayed
581581
from <parameter>origin_id</parameter> is of interest to the
582582
output plugin.
583583
<programlisting>
@@ -594,7 +594,7 @@ typedef bool (*LogicalDecodeChangeCB) (
594594
for transactions and changes that have been filtered away.
595595
</para>
596596
<para>
597-
This is useful when implementing cascading or multi directional
597+
This is useful when implementing cascading or multidirectional
598598
replication solutions. Filtering by the origin allows to
599599
prevent replicating the same changes back and forth in such
600600
setups. While transactions and changes also carry information

0 commit comments

Comments
 (0)