doc: Spell checking

doc/src/sgml/btree.sgml

@@ -298,7 +298,7 @@ returns bool
 
  <para>
   The essential semantics of an <function>in_range</function> function
-  depend on the two boolean flag parameters.  It should add or
+  depend on the two Boolean flag parameters.  It should add or
   subtract <replaceable>base</replaceable>
   and <replaceable>offset</replaceable>, then
   compare <replaceable>val</replaceable> to the result, as follows:

doc/src/sgml/client-auth.sgml

@@ -1729,7 +1729,7 @@ ldap[s]://<replaceable>host</replaceable>[:<replaceable>port</replaceable>]/<rep
      If <productname>PostgreSQL</productname> was compiled with
      <productname>OpenLDAP</productname> as the LDAP client library, the
      <literal>ldapserver</literal> setting may be omitted.  In that case, a
-     list of hostnames and ports is looked up via RFC 2782 DNS SRV records.
+     list of host names and ports is looked up via RFC 2782 DNS SRV records.
      The name <literal>_ldap._tcp.DOMAIN</literal> is looked up, where
      <literal>DOMAIN</literal> is extracted from <literal>ldapbasedn</literal>.
    </para>
@@ -1781,7 +1781,7 @@ host ... ldap ldapserver=ldap.example.net ldapbasedn="dc=example, dc=net" ldapse
 
    <para>
     Here is an example for a search+bind configuration that uses DNS SRV
-    discovery to find the hostname(s) and port(s) for the LDAP service for the
+    discovery to find the host name(s) and port(s) for the LDAP service for the
     domain name <literal>example.net</literal>:
 <programlisting>
 host ... ldap ldapbasedn="dc=example,dc=net"

doc/src/sgml/config.sgml

@@ -3624,9 +3624,9 @@ restore_command = 'copy "C:\\server\\archivedir\\%f" "%p"'  # Windows
       <listitem>
        <para>
         If set to <literal>on</literal> (the default), this option causes new
-        WAL files to be filled with zeroes.  On some filesystems, this ensures
+        WAL files to be filled with zeroes.  On some file systems, this ensures
         that space is allocated before we need to write WAL records.  However,
-        <firstterm>Copy-On-Write</firstterm> (COW) filesystems may not benefit
+        <firstterm>Copy-On-Write</firstterm> (COW) file systems may not benefit
         from this technique, so the option is given to skip the unnecessary
         work.  If set to <literal>off</literal>, only the final byte is written
         when the file is created so that it has the expected size.
@@ -3644,7 +3644,7 @@ restore_command = 'copy "C:\\server\\archivedir\\%f" "%p"'  # Windows
        <para>
         If set to <literal>on</literal> (the default), this option causes WAL
         files to be recycled by renaming them, avoiding the need to create new
-        ones.  On COW filesystems, it may be faster to create new ones, so the
+        ones.  On COW file systems, it may be faster to create new ones, so the
         option is given to disable this behavior.
        </para>
       </listitem>
@@ -8930,7 +8930,7 @@ dynamic_library_path = 'C:\tools\postgresql;H:\my_project\lib;$libdir'
        <para>
         When set to off, which is the default, <productname>PostgreSQL</productname>
         will raise a PANIC-level error on failure to flush modified data files
-        to the filesystem.  This causes the database server to crash.  This
+        to the file system.  This causes the database server to crash.  This
         parameter can only be set at server start.
        </para>
        <para>

doc/src/sgml/func.sgml

@@ -11624,7 +11624,7 @@ table2-mapping
    The result of each path evaluation step can be processed
    by one or more <type>jsonpath</type> operators and methods
    listed in <xref linkend="functions-sqljson-path-operators"/>.
-   Each method must be preceded by a dot, while arithmetic and boolean
+   Each method must be preceded by a dot, while arithmetic and Boolean
    operators are separated from the operands by spaces. For example,
    you can get an array size:
 <programlisting>
@@ -11719,7 +11719,7 @@ table2-mapping
 
    <listitem>
     <para>
-     A path expression can be a boolean predicate, although the SQL/JSON
+     A path expression can be a Boolean predicate, although the SQL/JSON
      standard allows predicates only in filters.  This is necessary for
      implementation of the <literal>@@</literal> operator. For example,
      the following<type>jsonpath</type> expression is valid in
@@ -12073,7 +12073,7 @@ table2-mapping
        </row>
        <row>
         <entry><literal>is unknown</literal></entry>
-        <entry>Tests whether a boolean condition is <literal>unknown</literal></entry>
+        <entry>Tests whether a Boolean condition is <literal>unknown</literal></entry>
         <entry><literal>[-1, 2, 7, "infinity"]</literal></entry>
         <entry><literal>$[*] ? ((@ > 0) is unknown)</literal></entry>
         <entry><literal>"infinity"</literal></entry>
@@ -12292,8 +12292,8 @@ table2-mapping
         <entry><literal>@@</literal></entry>
         <entry><type>jsonpath</type></entry>
         <entry>JSON path predicate check result for the specified JSON value.
-        Only first result item is taken into account.  If there is no results
-        or first result item is not bool, then <literal>NULL</literal>
+        Only first result item is taken into account.  If there are no results
+        or the first result item is not Boolean, then null
         is returned.</entry>
         <entry><literal>'{"a":[1,2,3,4,5]}'::jsonb @@ '$.a[*] > 2'</literal></entry>
        </row>
@@ -12958,8 +12958,8 @@ table2-mapping
         <entry><type>boolean</type></entry>
         <entry>
           Returns JSON path predicate result for the specified JSON value.
-          Only first result item is taken into account.  If there is no results
-          or first result item is not bool, then <literal>NULL</literal>
+          Only first result item is taken into account.  If there are no results
+          or the first result item is not Boolean, then null
           is returned.
         </entry>
         <entry>

doc/src/sgml/gin.sgml

@@ -227,7 +227,7 @@
       <para>
        <literal>pmatch</literal> is an output argument for use when partial match
        is supported.  To use it, <function>extractQuery</function> must allocate
-       an array of <literal>*nkeys</literal> bools and store its address at
+       an array of <literal>*nkeys</literal> <type>bool</type>s and store its address at
        <literal>*pmatch</literal>.  Each element of the array should be set to true
        if the corresponding key requires partial match, false if not.
        If <literal>*pmatch</literal> is set to <symbol>NULL</symbol> then GIN assumes partial match
@@ -255,12 +255,12 @@
   </variablelist>
 
   An operator class must also provide a function to check if an indexed item
-  matches the query. It comes in two flavors, a boolean <function>consistent</function>
+  matches the query. It comes in two flavors, a Boolean <function>consistent</function>
   function, and a ternary <function>triConsistent</function> function.
   <function>triConsistent</function> covers the functionality of both, so providing
-  <function>triConsistent</function> alone is sufficient. However, if the boolean
+  <function>triConsistent</function> alone is sufficient. However, if the Boolean
   variant is significantly cheaper to calculate, it can be advantageous to
-  provide both.  If only the boolean variant is provided, some optimizations
+  provide both.  If only the Boolean variant is provided, some optimizations
   that depend on refuting index items before fetching all the keys are
   disabled.
 
@@ -323,11 +323,11 @@
      <listitem>
       <para>
        <function>triConsistent</function> is similar to <function>consistent</function>,
-       but instead of booleans in the <literal>check</literal> vector, there are
+       but instead of Booleans in the <literal>check</literal> vector, there are
        three possible values for each
        key: <literal>GIN_TRUE</literal>, <literal>GIN_FALSE</literal> and
        <literal>GIN_MAYBE</literal>. <literal>GIN_FALSE</literal> and <literal>GIN_TRUE</literal>
-       have the same meaning as regular boolean values, while
+       have the same meaning as regular Boolean values, while
        <literal>GIN_MAYBE</literal> means that the presence of that key is not known.
        When <literal>GIN_MAYBE</literal> values are present, the function should only
        return <literal>GIN_TRUE</literal> if the item certainly matches whether or
@@ -342,7 +342,7 @@
        When there are no <literal>GIN_MAYBE</literal> values in the <literal>check</literal>
        vector, a <literal>GIN_MAYBE</literal> return value is the equivalent of
        setting the <literal>recheck</literal> flag in the
-       boolean <function>consistent</function> function.
+       Boolean <function>consistent</function> function.
       </para>
      </listitem>
     </varlistentry>

doc/src/sgml/json.sgml

@@ -849,8 +849,8 @@ SELECT jdoc->'guid', jdoc->'name' FROM api WHERE jdoc @> '{"tags": ["qu
         corresponds to the first array element.
        </para>
        <para>
-        Expression inside subscript may consititue an integer,
-        numeric expression or any other <literal>jsonpath</literal> expression
+        An expression in the subscript may be an integer,
+        numeric expression, or any other <literal>jsonpath</literal> expression
         returning single numeric value.  The <literal>last</literal> keyword
         can be used in the expression denoting the last subscript in an array.
         That's helpful for handling arrays of unknown length.

doc/src/sgml/spgist.sgml

@@ -213,7 +213,7 @@
   The <literal>quad_point_ops</literal>, <literal>kd_point_ops</literal> and
   <literal>poly_ops</literal> operator classes support the <literal>&lt;-&gt;</literal>
   ordering operator, which enables the k-nearest neighbor (<literal>k-NN</literal>)
-  search over indexed point or polygon datasets.
+  search over indexed point or polygon data sets.
  </para>
 
 </sect1>

doc/src/sgml/xfunc.sgml

@@ -1083,10 +1083,10 @@ SELECT x, g FROM tab, LATERAL generate_series(1,5) AS g;
 </programlisting>
      It would be exactly the same, except that in this specific example,
      the planner could choose to put <structname>g</structname> on the outside of the
-     nestloop join, since <structname>g</structname> has no actual lateral dependency
+     nested-loop join, since <structname>g</structname> has no actual lateral dependency
      on <structname>tab</structname>.  That would result in a different output row
      order.  Set-returning functions in the select list are always evaluated
-     as though they are on the inside of a nestloop join with the rest of
+     as though they are on the inside of a nested-loop join with the rest of
      the <literal>FROM</literal> clause, so that the function(s) are run to
      completion before the next row from the <literal>FROM</literal> clause is
      considered.
@@ -3441,14 +3441,14 @@ supportfn(internal) returns internal
    </para>
 
    <para>
-    For target functions that return boolean, it is often useful to estimate
-    the fraction of rows that will be selected by a WHERE clause using that
+    For target functions that return <type>boolean</type>, it is often useful to estimate
+    the fraction of rows that will be selected by a <literal>WHERE</literal> clause using that
     function.  This can be done by a support function that implements
     the <literal>SupportRequestSelectivity</literal> request type.
    </para>
 
    <para>
-    If the target function's runtime is highly dependent on its inputs,
+    If the target function's run time is highly dependent on its inputs,
     it may be useful to provide a non-constant cost estimate for it.
     This can be done by a support function that implements
     the <literal>SupportRequestCost</literal> request type.
@@ -3462,15 +3462,15 @@ supportfn(internal) returns internal
    </para>
 
    <para>
-    For target functions that return boolean, it may be possible to
-    convert a function call appearing in WHERE into an indexable operator
+    For target functions that return <type>boolean</type>, it may be possible to
+    convert a function call appearing in <literal>WHERE</literal> into an indexable operator
     clause or clauses.  The converted clauses might be exactly equivalent
     to the function's condition, or they could be somewhat weaker (that is,
     they might accept some values that the function condition does not).
     In the latter case the index condition is said to
     be <firstterm>lossy</firstterm>; it can still be used to scan an index,
     but the function call will have to be executed for each row returned by
-    the index to see if it really passes the WHERE condition or not.
+    the index to see if it really passes the <literal>WHERE</literal> condition or not.
     To create such conditions, the support function must implement
     the <literal>SupportRequestIndexCondition</literal> request type.
    </para>