<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:
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>
<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"
<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.
<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>
<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>
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>
<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
</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>
<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>
<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>
<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
</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.
<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
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>
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.
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>
</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.
</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.
</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>
projects / postgresql / commitdiff