doc: Spell checking
This commit is contained in:
parent
313f87a171
commit
594df378ff
@ -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:
|
||||
|
@ -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"
|
||||
|
@ -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>
|
||||
|
@ -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>
|
||||
|
@ -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>
|
||||
|
@ -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.
|
||||
|
@ -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><-></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>
|
||||
|
@ -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>
|
||||
|
Loading…
x
Reference in New Issue
Block a user