The essential semantics of an in_range function
- depend on the two boolean flag parameters. It should add or
+ depend on the two Boolean flag parameters. It should add or
subtract base
and offset, then
compare val to the result, as follows:
If
PostgreSQL was compiled with
OpenLDAP as the LDAP client library, the
ldapserver 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 _ldap._tcp.DOMAIN is looked up, where
DOMAIN is extracted from ldapbasedn.
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 example.net:
host ... ldap ldapbasedn="dc=example,dc=net"
If set to on (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,
- Copy-On-Write (COW) filesystems may not benefit
+ Copy-On-Write (COW) file systems may not benefit
from this technique, so the option is given to skip the unnecessary
work. If set to off, only the final byte is written
when the file is created so that it has the expected size.
If set to on (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.
When set to off, which is the default,
PostgreSQL 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.
The result of each path evaluation step can be processed
by one or more jsonpath operators and methods
listed in .
- 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:
- 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 @@ operator. For example,
the followingjsonpath expression is valid in
|
is unknown
- Tests whether a boolean condition is unknown
+ Tests whether a Boolean condition is unknown
[-1, 2, 7, "infinity"]
$[*] ? ((@ > 0) is unknown)
"infinity"
@@
jsonpath
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 NULL
+ 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.
'{"a":[1,2,3,4,5]}'::jsonb @@ '$.a[*] > 2'
boolean
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 NULL
+ 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.
pmatch is an output argument for use when partial match
is supported. To use it, extractQuery must allocate
- an array of *nkeys bools and store its address at
+ an array of *nkeys bools and store its address at
*pmatch. Each element of the array should be set to true
if the corresponding key requires partial match, false if not.
If *pmatch is set to NULL then GIN assumes partial match
An operator class must also provide a function to check if an indexed item
- matches the query. It comes in two flavors, a boolean consistent
+ matches the query. It comes in two flavors, a Boolean consistent
function, and a ternary triConsistent function.
triConsistent covers the functionality of both, so providing
- triConsistent alone is sufficient. However, if the boolean
+ triConsistent 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.
triConsistent is similar to consistent,
- but instead of booleans in the check vector, there are
+ but instead of Booleans in the check vector, there are
three possible values for each
key: GIN_TRUE, GIN_FALSE and
GIN_MAYBE. GIN_FALSE and GIN_TRUE
- have the same meaning as regular boolean values, while
+ have the same meaning as regular Boolean values, while
GIN_MAYBE means that the presence of that key is not known.
When GIN_MAYBE values are present, the function should only
return GIN_TRUE if the item certainly matches whether or
When there are no GIN_MAYBE values in the check
vector, a GIN_MAYBE return value is the equivalent of
setting the recheck flag in the
- boolean consistent function.
+ Boolean consistent function.
corresponds to the first array element.
- Expression inside subscript may consititue an integer,
- numeric expression or any other jsonpath expression
+ An expression in the subscript may be an integer,
+ numeric expression, or any other jsonpath expression
returning single numeric value. The last keyword
can be used in the expression denoting the last subscript in an array.
That's helpful for handling arrays of unknown length.
The quad_point_ops, kd_point_ops and
poly_ops operator classes support the <->
ordering operator, which enables the k-nearest neighbor (k-NN)
- search over indexed point or polygon datasets.
+ search over indexed point or polygon data sets.
It would be exactly the same, except that in this specific example,
the planner could choose to put g on the outside of the
- nestloop join, since g has no actual lateral dependency
+ nested-loop join, since g has no actual lateral dependency
on tab. 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 FROM clause, so that the function(s) are run to
completion before the next row from the FROM clause is
considered.
- 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 boolean, it is often useful to estimate
+ the fraction of rows that will be selected by a WHERE clause using that
function. This can be done by a support function that implements
the SupportRequestSelectivity request type.
- 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 SupportRequestCost request type.
- 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 boolean, it may be possible to
+ convert a function call appearing in WHERE 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 lossy; 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 WHERE condition or not.
To create such conditions, the support function must implement
the SupportRequestIndexCondition request type.
projects / postgresql.git / commitdiff