doc: Spell checking
This commit is contained in:
Peter Eisentraut
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:
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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,8 +3441,8 @@ 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>
|
||||
|
|
@ -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…
Reference in New Issue