the write-ahead log stream. It is printed as two hexadecimal numbers of
up to 8 digits each, separated by a slash; for example,
<literal>16/B374D848</>. The <type>pg_lsn</type> type supports the
- standard comparison operators, like <literal>=</literal> and
+ standard comparison operators, like <literal>=</literal> and
<literal>></literal>. Two LSNs can be subtracted using the
<literal>-</literal> operator; the result is the number of bytes separating
those write-ahead log positions.
</note>
<para>
The standard comparison operators shown in <xref
- linkend="functions-comparison-table"> are available for
- <type>jsonb</type>, but not for <type>json</type>. They follow the
+ linkend="functions-comparison-table"> are available for
+ <type>jsonb</type>, but not for <type>json</type>. They follow the
ordering rules for btree operations outlined at <xref
linkend="json-indexing">.
</para>
<entry><literal>select * from json_to_record('{"a":1,"b":[1,2,3],"c":"bar"}') as x(a int, b text, d text) </literal></entry>
<entry>
<programlisting>
- a | b | d
+ a | b | d
---+---------+---
- 1 | [1,2,3] |
+ 1 | [1,2,3] |
</programlisting>
</entry>
</row>
<literal>*>=</>.
These operators compare the internal binary representation of the two
rows. Two rows might have a different binary representation even
- though comparisons of the two rows with the equality operator is true.
+ though comparisons of the two rows with the equality operator is true.
The ordering of rows under these comparision operators is deterministic
but not otherwise meaningful. These operators are used internally for
materialized views and might be useful for other specialized purposes
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 that depend on
- refuting index items before fetching all the keys are disabled.
+ refuting index items before fetching all the keys are disabled.
<variablelist>
<varlistentry>
When <literal>GIN_MAYBE</> values are present, the function should only
return GIN_TRUE if the item matches whether or not the index item
contains the corresponding query keys. Likewise, the function must
- return GIN_FALSE only if the item does not match, whether or not it
+ return GIN_FALSE only if the item does not match, whether or not it
contains the GIN_MAYBE keys. If the result depends on the GIN_MAYBE
entries, i.e. the match cannot be confirmed or refuted based on the
known query keys, the function must return GIN_MAYBE.
</para>
<para>
- Note that the client's <filename>~/.postgresql/root.crt</> lists the top-level CAs
+ Note that the client's <filename>~/.postgresql/root.crt</> lists the top-level CAs
that are considered trusted for signing server certificates. In principle it need
not list the CA that signed the client's certificate, though in most cases
that CA would also be trusted for server certificates.
</para>
<para>
- The algorithms in <function>crypt()</> differ from the usual
+ The algorithms in <function>crypt()</> differ from the usual
MD5 or SHA1 hashing algorithms in the following respects:
</para>
<para>
The first argument is the relation to be prewarmed. The second argument
is the prewarming method to be used, as further discussed below; the third
- is the relation fork to be prewarmed, usually <literal>main</literal>.
+ is the relation fork to be prewarmed, usually <literal>main</literal>.
The fourth argument is the first block number to prewarm
(<literal>NULL</literal> is accepted as a synonym for zero). The fifth
argument is the last block number to prewarm (<literal>NULL</literal>
<para>
These additional checks are enabled through the configuration variables
- <varname>plpgsql.extra_warnings</> for warnings and
+ <varname>plpgsql.extra_warnings</> for warnings and
<varname>plpgsql.extra_errors</> for errors. Both can be set either to
a comma-separated list of checks, <literal>"none"</> or <literal>"all"</>.
The default is <literal>"none"</>. Currently the list of available checks
<term><varname>shadowed_variables</varname></term>
<listitem>
<para>
- Checks if a declaration shadows a previously defined variable.
+ Checks if a declaration shadows a previously defined variable.
</para>
</listitem>
</varlistentry>
following parameters can be used to specify an earlier stopping point.
At most one of <varname>recovery_target</>,
<varname>recovery_target_name</>, <varname>recovery_target_time</>, or
- <varname>recovery_target_xid</> can be specified.
+ <varname>recovery_target_xid</> can be specified.
</para>
<variablelist>
values to the <filename>postgresql.auto.conf</filename> file. With
<literal>DEFAULT</literal>, it removes a configuration entry from
<filename>postgresql.auto.conf</filename> file. The values will be
- effective after reload of server configuration (SIGHUP) or in next
+ effective after reload of server configuration (SIGHUP) or in next
server start based on the type of configuration parameter modified.
</para>
<para>
This command is not allowed inside transaction block or function.
</para>
-
+
<para>
- See <xref linkend="config-setting"> for other ways to set the parameters and
+ See <xref linkend="config-setting"> for other ways to set the parameters and
how they become effective.
</para>
</refsect1>
<listitem>
<para>
The approximate average size (in bytes) of the aggregate's state
- value, when using moving-aggregate mode. This works the same as
+ value, when using moving-aggregate mode. This works the same as
<replaceable>state_data_size</>.
</para>
</listitem>
</para>
<para>
Default expressions for the copied column definitions will only be
- copied if <literal>INCLUDING DEFAULTS</literal> is specified.
+ copied if <literal>INCLUDING DEFAULTS</literal> is specified.
Defaults that call database-modification functions, like
<function>nextval</>, create a linkage between the original and
new tables. The
<term><option>--xlogdir=<replaceable class="parameter">xlogdir</replaceable></option></term>
<listitem>
<para>
- Specifies the location for the transaction log directory.
+ Specifies the location for the transaction log directory.
<replaceable>xlogdir</replaceable> must be an absolute path.
The transaction log directory can only be specified when
the backup is in plain mode.
The command form <literal>\d+</literal> is identical, except that
more information is displayed: any comments associated with the
columns of the table are shown, as is the presence of OIDs in the
- table, the view definition if the relation is a view, a non-default
+ table, the view definition if the relation is a view, a non-default
<link linkend="SQL-CREATETABLE-REPLICA-IDENTITY">replica
identity</link> setting.
</para>
projects / postgresql / commitdiff