doc: Spell checking
This commit is contained in:
parent
313f87a171
commit
594df378ff
@ -298,7 +298,7 @@ returns bool
|
|||||||
|
|
||||||
<para>
|
<para>
|
||||||
The essential semantics of an <function>in_range</function> function
|
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>
|
subtract <replaceable>base</replaceable>
|
||||||
and <replaceable>offset</replaceable>, then
|
and <replaceable>offset</replaceable>, then
|
||||||
compare <replaceable>val</replaceable> to the result, as follows:
|
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
|
If <productname>PostgreSQL</productname> was compiled with
|
||||||
<productname>OpenLDAP</productname> as the LDAP client library, the
|
<productname>OpenLDAP</productname> as the LDAP client library, the
|
||||||
<literal>ldapserver</literal> setting may be omitted. In that case, a
|
<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
|
The name <literal>_ldap._tcp.DOMAIN</literal> is looked up, where
|
||||||
<literal>DOMAIN</literal> is extracted from <literal>ldapbasedn</literal>.
|
<literal>DOMAIN</literal> is extracted from <literal>ldapbasedn</literal>.
|
||||||
</para>
|
</para>
|
||||||
@ -1781,7 +1781,7 @@ host ... ldap ldapserver=ldap.example.net ldapbasedn="dc=example, dc=net" ldapse
|
|||||||
|
|
||||||
<para>
|
<para>
|
||||||
Here is an example for a search+bind configuration that uses DNS SRV
|
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>:
|
domain name <literal>example.net</literal>:
|
||||||
<programlisting>
|
<programlisting>
|
||||||
host ... ldap ldapbasedn="dc=example,dc=net"
|
host ... ldap ldapbasedn="dc=example,dc=net"
|
||||||
|
@ -3624,9 +3624,9 @@ restore_command = 'copy "C:\\server\\archivedir\\%f" "%p"' # Windows
|
|||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
If set to <literal>on</literal> (the default), this option causes new
|
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,
|
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
|
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
|
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.
|
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>
|
<para>
|
||||||
If set to <literal>on</literal> (the default), this option causes WAL
|
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
|
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.
|
option is given to disable this behavior.
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
@ -8930,7 +8930,7 @@ dynamic_library_path = 'C:\tools\postgresql;H:\my_project\lib;$libdir'
|
|||||||
<para>
|
<para>
|
||||||
When set to off, which is the default, <productname>PostgreSQL</productname>
|
When set to off, which is the default, <productname>PostgreSQL</productname>
|
||||||
will raise a PANIC-level error on failure to flush modified data files
|
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.
|
parameter can only be set at server start.
|
||||||
</para>
|
</para>
|
||||||
<para>
|
<para>
|
||||||
|
@ -11624,7 +11624,7 @@ table2-mapping
|
|||||||
The result of each path evaluation step can be processed
|
The result of each path evaluation step can be processed
|
||||||
by one or more <type>jsonpath</type> operators and methods
|
by one or more <type>jsonpath</type> operators and methods
|
||||||
listed in <xref linkend="functions-sqljson-path-operators"/>.
|
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,
|
operators are separated from the operands by spaces. For example,
|
||||||
you can get an array size:
|
you can get an array size:
|
||||||
<programlisting>
|
<programlisting>
|
||||||
@ -11719,7 +11719,7 @@ table2-mapping
|
|||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<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
|
standard allows predicates only in filters. This is necessary for
|
||||||
implementation of the <literal>@@</literal> operator. For example,
|
implementation of the <literal>@@</literal> operator. For example,
|
||||||
the following<type>jsonpath</type> expression is valid in
|
the following<type>jsonpath</type> expression is valid in
|
||||||
@ -12073,7 +12073,7 @@ table2-mapping
|
|||||||
</row>
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry><literal>is unknown</literal></entry>
|
<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>[-1, 2, 7, "infinity"]</literal></entry>
|
||||||
<entry><literal>$[*] ? ((@ > 0) is unknown)</literal></entry>
|
<entry><literal>$[*] ? ((@ > 0) is unknown)</literal></entry>
|
||||||
<entry><literal>"infinity"</literal></entry>
|
<entry><literal>"infinity"</literal></entry>
|
||||||
@ -12292,8 +12292,8 @@ table2-mapping
|
|||||||
<entry><literal>@@</literal></entry>
|
<entry><literal>@@</literal></entry>
|
||||||
<entry><type>jsonpath</type></entry>
|
<entry><type>jsonpath</type></entry>
|
||||||
<entry>JSON path predicate check result for the specified JSON value.
|
<entry>JSON path predicate check result for the specified JSON value.
|
||||||
Only first result item is taken into account. If there is no results
|
Only first result item is taken into account. If there are no results
|
||||||
or first result item is not bool, then <literal>NULL</literal>
|
or the first result item is not Boolean, then null
|
||||||
is returned.</entry>
|
is returned.</entry>
|
||||||
<entry><literal>'{"a":[1,2,3,4,5]}'::jsonb @@ '$.a[*] > 2'</literal></entry>
|
<entry><literal>'{"a":[1,2,3,4,5]}'::jsonb @@ '$.a[*] > 2'</literal></entry>
|
||||||
</row>
|
</row>
|
||||||
@ -12958,8 +12958,8 @@ table2-mapping
|
|||||||
<entry><type>boolean</type></entry>
|
<entry><type>boolean</type></entry>
|
||||||
<entry>
|
<entry>
|
||||||
Returns JSON path predicate result for the specified JSON value.
|
Returns JSON path predicate result for the specified JSON value.
|
||||||
Only first result item is taken into account. If there is no results
|
Only first result item is taken into account. If there are no results
|
||||||
or first result item is not bool, then <literal>NULL</literal>
|
or the first result item is not Boolean, then null
|
||||||
is returned.
|
is returned.
|
||||||
</entry>
|
</entry>
|
||||||
<entry>
|
<entry>
|
||||||
|
@ -227,7 +227,7 @@
|
|||||||
<para>
|
<para>
|
||||||
<literal>pmatch</literal> is an output argument for use when partial match
|
<literal>pmatch</literal> is an output argument for use when partial match
|
||||||
is supported. To use it, <function>extractQuery</function> must allocate
|
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
|
<literal>*pmatch</literal>. Each element of the array should be set to true
|
||||||
if the corresponding key requires partial match, false if not.
|
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
|
If <literal>*pmatch</literal> is set to <symbol>NULL</symbol> then GIN assumes partial match
|
||||||
@ -255,12 +255,12 @@
|
|||||||
</variablelist>
|
</variablelist>
|
||||||
|
|
||||||
An operator class must also provide a function to check if an indexed item
|
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, and a ternary <function>triConsistent</function> function.
|
||||||
<function>triConsistent</function> covers the functionality of both, so providing
|
<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
|
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
|
that depend on refuting index items before fetching all the keys are
|
||||||
disabled.
|
disabled.
|
||||||
|
|
||||||
@ -323,11 +323,11 @@
|
|||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
<function>triConsistent</function> is similar to <function>consistent</function>,
|
<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
|
three possible values for each
|
||||||
key: <literal>GIN_TRUE</literal>, <literal>GIN_FALSE</literal> and
|
key: <literal>GIN_TRUE</literal>, <literal>GIN_FALSE</literal> and
|
||||||
<literal>GIN_MAYBE</literal>. <literal>GIN_FALSE</literal> and <literal>GIN_TRUE</literal>
|
<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.
|
<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
|
When <literal>GIN_MAYBE</literal> values are present, the function should only
|
||||||
return <literal>GIN_TRUE</literal> if the item certainly matches whether or
|
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>
|
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
|
vector, a <literal>GIN_MAYBE</literal> return value is the equivalent of
|
||||||
setting the <literal>recheck</literal> flag in the
|
setting the <literal>recheck</literal> flag in the
|
||||||
boolean <function>consistent</function> function.
|
Boolean <function>consistent</function> function.
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
|
@ -849,8 +849,8 @@ SELECT jdoc->'guid', jdoc->'name' FROM api WHERE jdoc @> '{"tags": ["qu
|
|||||||
corresponds to the first array element.
|
corresponds to the first array element.
|
||||||
</para>
|
</para>
|
||||||
<para>
|
<para>
|
||||||
Expression inside subscript may consititue an integer,
|
An expression in the subscript may be an integer,
|
||||||
numeric expression or any other <literal>jsonpath</literal> expression
|
numeric expression, or any other <literal>jsonpath</literal> expression
|
||||||
returning single numeric value. The <literal>last</literal> keyword
|
returning single numeric value. The <literal>last</literal> keyword
|
||||||
can be used in the expression denoting the last subscript in an array.
|
can be used in the expression denoting the last subscript in an array.
|
||||||
That's helpful for handling arrays of unknown length.
|
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
|
The <literal>quad_point_ops</literal>, <literal>kd_point_ops</literal> and
|
||||||
<literal>poly_ops</literal> operator classes support the <literal><-></literal>
|
<literal>poly_ops</literal> operator classes support the <literal><-></literal>
|
||||||
ordering operator, which enables the k-nearest neighbor (<literal>k-NN</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>
|
</para>
|
||||||
|
|
||||||
</sect1>
|
</sect1>
|
||||||
|
@ -1083,10 +1083,10 @@ SELECT x, g FROM tab, LATERAL generate_series(1,5) AS g;
|
|||||||
</programlisting>
|
</programlisting>
|
||||||
It would be exactly the same, except that in this specific example,
|
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
|
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
|
on <structname>tab</structname>. That would result in a different output row
|
||||||
order. Set-returning functions in the select list are always evaluated
|
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
|
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
|
completion before the next row from the <literal>FROM</literal> clause is
|
||||||
considered.
|
considered.
|
||||||
@ -3441,14 +3441,14 @@ supportfn(internal) returns internal
|
|||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
For target functions that return boolean, it is often useful to estimate
|
For target functions that return <type>boolean</type>, it is often useful to estimate
|
||||||
the fraction of rows that will be selected by a WHERE clause using that
|
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
|
function. This can be done by a support function that implements
|
||||||
the <literal>SupportRequestSelectivity</literal> request type.
|
the <literal>SupportRequestSelectivity</literal> request type.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<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.
|
it may be useful to provide a non-constant cost estimate for it.
|
||||||
This can be done by a support function that implements
|
This can be done by a support function that implements
|
||||||
the <literal>SupportRequestCost</literal> request type.
|
the <literal>SupportRequestCost</literal> request type.
|
||||||
@ -3462,15 +3462,15 @@ supportfn(internal) returns internal
|
|||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
For target functions that return boolean, it may be possible to
|
For target functions that return <type>boolean</type>, it may be possible to
|
||||||
convert a function call appearing in WHERE into an indexable operator
|
convert a function call appearing in <literal>WHERE</literal> into an indexable operator
|
||||||
clause or clauses. The converted clauses might be exactly equivalent
|
clause or clauses. The converted clauses might be exactly equivalent
|
||||||
to the function's condition, or they could be somewhat weaker (that is,
|
to the function's condition, or they could be somewhat weaker (that is,
|
||||||
they might accept some values that the function condition does not).
|
they might accept some values that the function condition does not).
|
||||||
In the latter case the index condition is said to
|
In the latter case the index condition is said to
|
||||||
be <firstterm>lossy</firstterm>; it can still be used to scan an index,
|
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
|
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
|
To create such conditions, the support function must implement
|
||||||
the <literal>SupportRequestIndexCondition</literal> request type.
|
the <literal>SupportRequestIndexCondition</literal> request type.
|
||||||
</para>
|
</para>
|
||||||
|
Loading…
x
Reference in New Issue
Block a user