mirror of
https://github.com/postgres/postgres.git
synced 2025-05-17 06:41:24 +03:00
doc: Spell checking
This commit is contained in:
parent
9b3ef66afe
commit
9fb149573d
@ -408,13 +408,13 @@
|
||||
<entry><structfield>aggfinalextra</structfield></entry>
|
||||
<entry><type>bool</type></entry>
|
||||
<entry></entry>
|
||||
<entry>True to pass extra dummy arguments to aggfinalfn</entry>
|
||||
<entry>True to pass extra dummy arguments to <structfield>aggfinalfn</structfield></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><structfield>aggmfinalextra</structfield></entry>
|
||||
<entry><type>bool</type></entry>
|
||||
<entry></entry>
|
||||
<entry>True to pass extra dummy arguments to aggmfinalfn</entry>
|
||||
<entry>True to pass extra dummy arguments to <structfield>aggmfinalfn</structfield></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><structfield>aggsortop</structfield></entry>
|
||||
@ -838,7 +838,7 @@
|
||||
<entry><structfield>amopsortfamily</structfield></entry>
|
||||
<entry><type>oid</type></entry>
|
||||
<entry><literal><link linkend="catalog-pg-opfamily"><structname>pg_opfamily</structname></link>.oid</literal></entry>
|
||||
<entry>The btree operator family this entry sorts according to, if an
|
||||
<entry>The B-tree operator family this entry sorts according to, if an
|
||||
ordering operator; zero if a search operator</entry>
|
||||
</row>
|
||||
|
||||
@ -853,7 +853,7 @@
|
||||
<replaceable>indexed_column</>
|
||||
<replaceable>operator</>
|
||||
<replaceable>constant</>.
|
||||
Obviously, such an operator must return boolean, and its left-hand input
|
||||
Obviously, such an operator must return <type>boolean</type>, and its left-hand input
|
||||
type must match the index's column data type.
|
||||
</para>
|
||||
|
||||
@ -868,13 +868,13 @@
|
||||
its left-hand input type must match the index's column data type.
|
||||
The exact semantics of the <literal>ORDER BY</> are specified by the
|
||||
<structfield>amopsortfamily</structfield> column, which must reference
|
||||
a btree operator family for the operator's result type.
|
||||
a B-tree operator family for the operator's result type.
|
||||
</para>
|
||||
|
||||
<note>
|
||||
<para>
|
||||
At present, it's assumed that the sort order for an ordering operator
|
||||
is the default for the referenced opfamily, i.e., <literal>ASC NULLS
|
||||
is the default for the referenced operator family, i.e., <literal>ASC NULLS
|
||||
LAST</>. This might someday be relaxed by adding additional columns
|
||||
to specify sort options explicitly.
|
||||
</para>
|
||||
@ -974,7 +974,7 @@
|
||||
these match the input data type(s) of the support procedure itself, for
|
||||
others not. There is a notion of <quote>default</> support procedures for
|
||||
an index, which are those with <structfield>amproclefttype</> and
|
||||
<structfield>amprocrighttype</> both equal to the index opclass's
|
||||
<structfield>amprocrighttype</> both equal to the index operator class's
|
||||
<structfield>opcintype</>.
|
||||
</para>
|
||||
|
||||
@ -1959,7 +1959,7 @@
|
||||
<literal>d</> = default (primary key, if any),
|
||||
<literal>n</> = nothing,
|
||||
<literal>f</> = all columns
|
||||
<literal>i</> = index with indisreplident set, or default
|
||||
<literal>i</> = index with <structfield>indisreplident</structfield> set, or default
|
||||
</entry>
|
||||
</row>
|
||||
|
||||
@ -5275,7 +5275,7 @@
|
||||
<entry><structfield>datoid</structfield></entry>
|
||||
<entry><type>oid</type></entry>
|
||||
<entry><literal><link linkend="catalog-pg-database"><structname>pg_database</structname></link>.oid</literal></entry>
|
||||
<entry>The oid of the database this slot is associated with, or
|
||||
<entry>The OID of the database this slot is associated with, or
|
||||
null. Only logical slots have an associated database.</entry>
|
||||
</row>
|
||||
|
||||
|
@ -2603,7 +2603,7 @@ include_dir 'conf.d'
|
||||
<para>
|
||||
The name of a standby server for this purpose is the
|
||||
<varname>application_name</> setting of the standby, as set in the
|
||||
<varname>primary_conninfo</> of the standby's walreceiver. There is
|
||||
<varname>primary_conninfo</> of the standby's WAL receiver. There is
|
||||
no mechanism to enforce uniqueness. In case of duplicates one of the
|
||||
matching standbys will be chosen to be the synchronous standby, though
|
||||
exactly which one is indeterminate.
|
||||
|
@ -4487,7 +4487,7 @@ SELECT * FROM pg_attribute
|
||||
<para>
|
||||
The <type>pg_lsn</type> data type can be used to store LSN (Log Sequence
|
||||
Number) data which is a pointer to a location in the XLOG. This type is a
|
||||
representation of XLogRecPtr and an internal system type of
|
||||
representation of <type>XLogRecPtr</type> and an internal system type of
|
||||
<productname>PostgreSQL</productname>.
|
||||
</para>
|
||||
|
||||
|
@ -430,7 +430,7 @@ ExecForeignInsert (EState *estate,
|
||||
<literal>rinfo</> is the <structname>ResultRelInfo</> struct describing
|
||||
the target foreign table.
|
||||
<literal>slot</> contains the tuple to be inserted; it will match the
|
||||
rowtype definition of the foreign table.
|
||||
row-type definition of the foreign table.
|
||||
<literal>planSlot</> contains the tuple that was generated by the
|
||||
<structname>ModifyTable</> plan node's subplan; it differs from
|
||||
<literal>slot</> in possibly containing additional <quote>junk</>
|
||||
@ -476,7 +476,7 @@ ExecForeignUpdate (EState *estate,
|
||||
<literal>rinfo</> is the <structname>ResultRelInfo</> struct describing
|
||||
the target foreign table.
|
||||
<literal>slot</> contains the new data for the tuple; it will match the
|
||||
rowtype definition of the foreign table.
|
||||
row-type definition of the foreign table.
|
||||
<literal>planSlot</> contains the tuple that was generated by the
|
||||
<structname>ModifyTable</> plan node's subplan; it differs from
|
||||
<literal>slot</> in possibly containing additional <quote>junk</>
|
||||
|
@ -10162,7 +10162,7 @@ table2-mapping
|
||||
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
|
||||
ordering rules for btree operations outlined at <xref
|
||||
ordering rules for B-tree operations outlined at <xref
|
||||
linkend="json-indexing">.
|
||||
</para>
|
||||
<para>
|
||||
@ -10269,7 +10269,7 @@ table2-mapping
|
||||
(recursively) to arrays and objects; otherwise, if there is a cast
|
||||
from the type to <type>json</type>, the cast function will be used to
|
||||
perform the conversion; otherwise, a JSON scalar value is produced.
|
||||
For any scalar type other than a number, a boolean, or a null value,
|
||||
For any scalar type other than a number, a Boolean, or a null value,
|
||||
the text representation will be used, properly quoted and escaped
|
||||
so that it is a valid JSON string.
|
||||
</entry>
|
||||
@ -14007,7 +14007,7 @@ AND
|
||||
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.
|
||||
The ordering of rows under these comparision operators is deterministic
|
||||
The ordering of rows under these comparison operators is deterministic
|
||||
but not otherwise meaningful. These operators are used internally for
|
||||
materialized views and might be useful for other specialized purposes
|
||||
such as replication but are not intended to be generally useful for
|
||||
@ -15461,32 +15461,32 @@ SELECT pg_type_is_visible('myschema.widget'::regtype);
|
||||
<row>
|
||||
<entry><literal><function>to_regclass(<parameter>rel_name</parameter>)</function></literal></entry>
|
||||
<entry><type>regclass</type></entry>
|
||||
<entry>get the oid of the named relation</entry>
|
||||
<entry>get the OID of the named relation</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><literal><function>to_regproc(<parameter>func_name</parameter>)</function></literal></entry>
|
||||
<entry><type>regproc</type></entry>
|
||||
<entry>get the oid of the named function</entry>
|
||||
<entry>get the OID of the named function</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><literal><function>to_regprocedure(<parameter>func_name</parameter>)</function></literal></entry>
|
||||
<entry><type>regprocedure</type></entry>
|
||||
<entry>get the oid of the named function</entry>
|
||||
<entry>get the OID of the named function</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><literal><function>to_regoper(<parameter>operator_name</parameter>)</function></literal></entry>
|
||||
<entry><type>regoper</type></entry>
|
||||
<entry>get the oid of the named operator</entry>
|
||||
<entry>get the OID of the named operator</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><literal><function>to_regoperator(<parameter>operator_name</parameter>)</function></literal></entry>
|
||||
<entry><type>regoperator</type></entry>
|
||||
<entry>get the oid of the named operator</entry>
|
||||
<entry>get the OID of the named operator</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><literal><function>to_regtype(<parameter>type_name</parameter>)</function></literal></entry>
|
||||
<entry><type>regtype</type></entry>
|
||||
<entry>get the oid of the named type</entry>
|
||||
<entry>get the OID of the named type</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
@ -16619,8 +16619,8 @@ postgres=# SELECT * FROM pg_xlogfile_name_offset(pg_stop_backup());
|
||||
<entry>
|
||||
Creates a new physical replication slot named
|
||||
<parameter>slot_name</parameter>. Streaming changes from a physical slot
|
||||
is only possible with the walsender protocol - see <xref
|
||||
linkend="protocol-replication">. Corresponds to the walsender protocol
|
||||
is only possible with the streaming-replication protocol - see <xref
|
||||
linkend="protocol-replication">. Corresponds to the replication protocol
|
||||
command <literal>CREATE_REPLICATION_SLOT ... PHYSICAL</literal>.
|
||||
</entry>
|
||||
</row>
|
||||
@ -16636,7 +16636,7 @@ postgres=# SELECT * FROM pg_xlogfile_name_offset(pg_stop_backup());
|
||||
</entry>
|
||||
<entry>
|
||||
Drops the physical or logical replication slot
|
||||
named <parameter>slot_name</parameter>. Same as walsender protocol
|
||||
named <parameter>slot_name</parameter>. Same as replication protocol
|
||||
command <literal>DROP_REPLICATION_SLOT</>.
|
||||
</entry>
|
||||
</row>
|
||||
|
@ -1894,7 +1894,7 @@ if (!triggered)
|
||||
might want to make adjustments to handle the period when
|
||||
<varname>hot_standby_feedback</> feedback is not being provided.
|
||||
For example, consider increasing <varname>max_standby_archive_delay</>
|
||||
so that queries are not rapidly cancelled by conflicts in WAL archive
|
||||
so that queries are not rapidly canceled by conflicts in WAL archive
|
||||
files during disconnected periods. You should also consider increasing
|
||||
<varname>max_standby_streaming_delay</> to avoid rapid cancellations
|
||||
by newly-arrived streaming WAL entries after reconnection.
|
||||
|
@ -168,7 +168,7 @@ ambuild (Relation heapRelation,
|
||||
void
|
||||
ambuildempty (Relation indexRelation);
|
||||
</programlisting>
|
||||
Build an empty index, and write it to the initialization fork (INIT_FORKNUM)
|
||||
Build an empty index, and write it to the initialization fork (<symbol>INIT_FORKNUM</symbol>)
|
||||
of the given relation. This method is called only for unlogged tables; the
|
||||
empty index written to the initialization fork will be copied over the main
|
||||
relation fork on each server restart.
|
||||
@ -278,7 +278,7 @@ amcanreturn (Relation indexRelation);
|
||||
</programlisting>
|
||||
Check whether the index can support <firstterm>index-only scans</> by
|
||||
returning the indexed column values for an index entry in the form of an
|
||||
IndexTuple. Return TRUE if so, else FALSE. If the index AM can never
|
||||
<structname>IndexTuple</structname>. Return TRUE if so, else FALSE. If the index AM can never
|
||||
support index-only scans (an example is hash, which stores only
|
||||
the hash values not the original data), it is sufficient to set its
|
||||
<structfield>amcanreturn</> field to zero in <structname>pg_am</>.
|
||||
|
@ -354,7 +354,7 @@ SELECT '"foo"'::jsonb ? 'foo';
|
||||
keys or key/value pairs occurring within a large number of
|
||||
<type>jsonb</> documents (datums).
|
||||
Two GIN <quote>operator classes</> are provided, offering different
|
||||
performance and flexibility tradeoffs.
|
||||
performance and flexibility trade-offs.
|
||||
</para>
|
||||
<para>
|
||||
The default GIN operator class for <type>jsonb</> supports queries with
|
||||
|
@ -136,7 +136,7 @@ PGconn *PQconnectdbParams(const char * const *keywords,
|
||||
</para>
|
||||
|
||||
<para>
|
||||
If any parameter is NULL or an emptry string, the corresponding
|
||||
If any parameter is <symbol>NULL</symbol> or an emptry string, the corresponding
|
||||
environment variable (see <xref linkend="libpq-envars">) is checked.
|
||||
If the environment variable is not set either, then the indicated
|
||||
built-in defaults are used.
|
||||
|
@ -362,8 +362,8 @@ CREATE TABLE another_catalog_table(data text) WITH (user_catalog_table = true);
|
||||
various callbacks it needs to provide.
|
||||
</para>
|
||||
<para>
|
||||
Concurrent transactions are decoded in commit order and only changes
|
||||
belonging to a specific transaction are decoded inbetween
|
||||
Concurrent transactions are decoded in commit order, and only changes
|
||||
belonging to a specific transaction are decoded between
|
||||
the <literal>begin</literal> and <literal>commit</literal>
|
||||
callbacks. Transactions that were rolled back explicitly or implicitly
|
||||
never get
|
||||
@ -432,7 +432,7 @@ typedef void (*LogicalDecodeShutdownCB) (
|
||||
<title>Transaction Begin Callback</title>
|
||||
<para>
|
||||
The required <function>begin_cb</function> callback is called whenever a
|
||||
start of a commited transaction has been decoded. Aborted transactions
|
||||
start of a committed transaction has been decoded. Aborted transactions
|
||||
and their contents never get decoded.
|
||||
<programlisting>
|
||||
typedef void (*LogicalDecodeBeginCB) (
|
||||
@ -469,7 +469,7 @@ typedef void (*LogicalDecodeCommitCB) (
|
||||
individual row modification inside a transaction, may it be
|
||||
an <command>INSERT</command>, <command>UPDATE</command>
|
||||
or <command>DELETE</command>. Even if the original command modified
|
||||
several rows at once the callback will be called indvidually for each
|
||||
several rows at once the callback will be called individually for each
|
||||
row.
|
||||
<programlisting>
|
||||
typedef void (*LogicalDecodeChangeCB) (
|
||||
|
@ -631,7 +631,7 @@ postgres: <replaceable>user</> <replaceable>database</> <replaceable>host</> <re
|
||||
<row>
|
||||
<entry><structfield>backend_xid</structfield></entry>
|
||||
<entry><type>xid</type></entry>
|
||||
<entry>Toplevel transaction identifier of this backend, if any.</entry>
|
||||
<entry>Top-level transaction identifier of this backend, if any.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><structfield>backend_xmin</structfield></entry>
|
||||
|
@ -199,7 +199,7 @@
|
||||
|
||||
<para>
|
||||
For security reasons, non-superusers are not allowed to see the SQL
|
||||
text or queryid of queries executed by other users. They can see
|
||||
text or <structfield>queryid</structfield> of queries executed by other users. They can see
|
||||
the statistics, however, if the view has been installed in their
|
||||
database.
|
||||
</para>
|
||||
|
@ -1302,7 +1302,7 @@
|
||||
|
||||
<para>
|
||||
To initiate streaming replication, the frontend sends the
|
||||
<literal>replication</> parameter in the startup message. A boolean value
|
||||
<literal>replication</> parameter in the startup message. A Boolean value
|
||||
of <literal>true</> tells the backend to go into walsender mode, wherein a
|
||||
small set of replication commands can be issued instead of SQL statements. Only
|
||||
the simple query protocol can be used in walsender mode.
|
||||
|
@ -650,7 +650,7 @@ FROM (VALUES ('anne', 'smith'), ('bob', 'jones'), ('joe', 'blow'))
|
||||
Table functions may also be combined using the <literal>ROWS FROM</>
|
||||
syntax, with the results returned in parallel columns; the number of
|
||||
result rows in this case is that of the largest function result, with
|
||||
smaller results padded with NULLs to match.
|
||||
smaller results padded with null values to match.
|
||||
</para>
|
||||
|
||||
<synopsis>
|
||||
|
@ -427,7 +427,7 @@ restore_command = 'copy "C:\\server\\archivedir\\%f" "%p"' # Windows
|
||||
on master and the time on the current standby. Delays
|
||||
in transfer because of networks or cascading replication configurations
|
||||
may reduce the actual wait time significantly. If the system
|
||||
clocks on master and standby are not synchronised, this may lead to
|
||||
clocks on master and standby are not synchronized, this may lead to
|
||||
recovery applying records earlier than expected; but that is not a
|
||||
major issue because useful settings of the parameter are much larger
|
||||
than typical time deviations between servers. Be careful to allow for
|
||||
@ -445,7 +445,7 @@ restore_command = 'copy "C:\\server\\archivedir\\%f" "%p"' # Windows
|
||||
</para>
|
||||
<para>
|
||||
This parameter is intended for use with streaming replication deployments,
|
||||
however, if the parameter is specified it will be honoured in all cases.
|
||||
however, if the parameter is specified it will be honored in all cases.
|
||||
Synchronous replication is not affected by this setting because there is
|
||||
not yet any setting to request synchronous apply of transaction commits.
|
||||
<varname>hot_standby_feedback</> will be delayed by use of this feature
|
||||
|
@ -358,7 +358,7 @@ CREATE VIEW vista AS SELECT text 'Hello World' AS hello;
|
||||
<para>
|
||||
If an automatically updatable view is marked with the
|
||||
<literal>security_barrier</> property then all the view's <literal>WHERE</>
|
||||
conditions (and any conditions using operators which are marked as LEAKPROOF)
|
||||
conditions (and any conditions using operators which are marked as <literal>LEAKPROOF</literal>)
|
||||
will always be evaluated before any conditions that a user of the view has
|
||||
added. See <xref linkend="rules-privileges"> for full details. Note that,
|
||||
due to this, rows which are not ultimately returned (because they do not
|
||||
|
@ -183,7 +183,7 @@ PostgreSQL documentation
|
||||
|
||||
<para>
|
||||
The following command-line options control the location and format of the
|
||||
output and other replication behaviour:
|
||||
output and other replication behavior:
|
||||
|
||||
<variablelist>
|
||||
|
||||
|
@ -111,13 +111,13 @@
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
Tighten checks for multi-dimensional <link
|
||||
Tighten checks for multidimensional <link
|
||||
linkend="arrays">array</link> input (Bruce Momjian)
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Previously an input array string that started with a single-element
|
||||
array dimension could later contain multi-dimensional segments,
|
||||
array dimension could later contain multidimensional segments,
|
||||
e.g. <literal>'{{1}, {2,3}}'::int[]</>.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -198,7 +198,7 @@
|
||||
<listitem>
|
||||
<para>
|
||||
Rename <link linkend="SQL-EXPLAIN"><command>EXPLAIN
|
||||
ANALYZE</></link>'s "total runtime" output to "execution time"
|
||||
ANALYZE</></link>'s <quote>total runtime</quote> output to <quote>execution time</quote>
|
||||
(Tom Lane)
|
||||
</para>
|
||||
|
||||
@ -565,7 +565,7 @@
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
Improve speed of accesessing many different <link
|
||||
Improve speed of accessing many different <link
|
||||
linkend="SQL-CREATESEQUENCE">sequences</link> in the same session
|
||||
(David Rowley)
|
||||
</para>
|
||||
@ -775,7 +775,7 @@
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
Allow printf-style space padding to be specified in <link
|
||||
Allow <function>printf</function>-style space padding to be specified in <link
|
||||
linkend="guc-log-line-prefix"><varname>log_line_prefix</></link>
|
||||
(David Rowley)
|
||||
</para>
|
||||
@ -1098,7 +1098,7 @@
|
||||
|
||||
<para>
|
||||
Previously only unquoted matching strings would be imported
|
||||
as NULLs.
|
||||
as null values.
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
@ -1370,23 +1370,23 @@
|
||||
<listitem>
|
||||
<para>
|
||||
Add structured (non-text) data type (<link
|
||||
linkend="datatype-json"><type>JSONB</></link>) for storing
|
||||
<type>JSON</> data (Oleg Bartunov, Teodor Sigaev, Alexander
|
||||
linkend="datatype-json"><type>jsonb</></link>) for storing
|
||||
JSON data (Oleg Bartunov, Teodor Sigaev, Alexander
|
||||
Korotkov, Peter Geoghegan, and Andrew Dunstan)
|
||||
</para>
|
||||
|
||||
<para>
|
||||
This allows for faster access to values in the <type>JSON</>
|
||||
document and faster and more useful indexing of <type>JSON</>.
|
||||
Scalar values in <type>JSONB</> documents are typed as appropriate
|
||||
This allows for faster access to values in the JSON
|
||||
document and faster and more useful indexing of JSON.
|
||||
Scalar values in <type>jsonb</> documents are typed as appropriate
|
||||
scalar SQL types.
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
Add new <type>JSON</> functions to allow for the construction
|
||||
of arbitrarily complex json trees (Andrew Dunstan, Laurence Rowe)
|
||||
Add new JSON functions to allow for the construction
|
||||
of arbitrarily complex JSON trees (Andrew Dunstan, Laurence Rowe)
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@ -1402,7 +1402,7 @@
|
||||
<para>
|
||||
Add <link
|
||||
linkend="functions-json-processing-table"><function>json_typeof()</></link>
|
||||
to return the data type of a <type>JSON</> value (Andrew Tipton)
|
||||
to return the data type of a <type>json</> value (Andrew Tipton)
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
@ -1782,14 +1782,14 @@
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
Allow <function>sizeof()</> in <link linkend="ecpg">ecpg</link>
|
||||
Allow <function>sizeof()</> in <link linkend="ecpg">ECPG</link>
|
||||
C array definitions (Michael Meskes)
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
Have <link linkend="ecpg">ecpg</link> properly handle nesting
|
||||
Have <link linkend="ecpg">ECPG</link> properly handle nesting
|
||||
requirements in C and <acronym>SQL</> mode for C-style comments
|
||||
(Michael Meskes)
|
||||
</para>
|
||||
@ -1871,12 +1871,12 @@
|
||||
<listitem>
|
||||
<para>
|
||||
Have <application>psql</> <command>\d+</> output an
|
||||
<literal>OID</> line only if an oid column exists in a table
|
||||
<literal>OID</> line only if an <literal>oid</literal> column exists in a table
|
||||
(Bruce Momjian)
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Previously, the presence or absence of an oid column was always
|
||||
Previously, the presence or absence of an <literal>oid</literal> column was always
|
||||
reported.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -2251,7 +2251,7 @@
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
Avoid most uses of dlltool in <productname>Cygwin</> and
|
||||
Avoid most uses of <command>dlltool</command> in <productname>Cygwin</> and
|
||||
<productname>Mingw</> builds (Marco Atzeri, Hiroshi Inoue)
|
||||
</para>
|
||||
</listitem>
|
||||
@ -2294,7 +2294,7 @@
|
||||
|
||||
<para>
|
||||
This allows the creation of version 4 <acronym>UUID</>s without
|
||||
requiring the installation of uuid-ossp.
|
||||
requiring the installation of <literal>uuid-ossp</literal>.
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
@ -2317,11 +2317,11 @@
|
||||
<listitem>
|
||||
<para>
|
||||
Have <link linkend="pgstattuple"><application>pgstattuple</></link>
|
||||
functions use regclass-type arguments (Satoshi Nagayasu)
|
||||
functions use <type>regclass</type>-type arguments (Satoshi Nagayasu)
|
||||
</para>
|
||||
|
||||
<para>
|
||||
While text-type arguments are still supported, they will be
|
||||
While <type>text</type>-type arguments are still supported, they will be
|
||||
removed in a later major release.
|
||||
</para>
|
||||
</listitem>
|
||||
|
@ -1179,7 +1179,7 @@ SPIPlanPtr SPI_prepare_params(const char * <parameter>command</parameter>,
|
||||
<term><literal>void * <parameter>parserSetupArg</parameter></literal></term>
|
||||
<listitem>
|
||||
<para>
|
||||
passthrough argument for <parameter>parserSetup</parameter>
|
||||
pass-through argument for <parameter>parserSetup</parameter>
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
@ -217,8 +217,8 @@ CREATE AGGREGATE sum (complex)
|
||||
|
||||
<para>
|
||||
The forward transition function for moving-aggregate mode is not allowed
|
||||
to return NULL as the new state value. If the inverse transition
|
||||
function returns NULL, this is taken as an indication that the inverse
|
||||
to return null as the new state value. If the inverse transition
|
||||
function returns null, this is taken as an indication that the inverse
|
||||
function cannot reverse the state calculation for this particular input,
|
||||
and so the aggregate calculation will be redone from scratch for the
|
||||
current frame starting position. This convention allows moving-aggregate
|
||||
@ -352,7 +352,7 @@ SELECT attrelid::regclass, array_accum(atttypid::regtype)
|
||||
no SQL-level equivalent for it. To address this case, it is possible to
|
||||
declare the final function as taking extra <quote>dummy</> arguments
|
||||
that match the input arguments of the aggregate. Such dummy arguments
|
||||
are always passed as NULLs since no specific value is available when the
|
||||
are always passed as null values since no specific value is available when the
|
||||
final function is called. Their only use is to allow a polymorphic
|
||||
final function's result type to be connected to the aggregate's input
|
||||
type(s). For example, the definition of the built-in
|
||||
@ -496,7 +496,7 @@ SELECT percentile_disc(0.5) WITHIN GROUP (ORDER BY income) FROM households;
|
||||
same definition as for normal aggregates, but note that the direct
|
||||
arguments (if any) are not provided. The final function receives
|
||||
the last state value, the values of the direct arguments if any,
|
||||
and (if <literal>finalfunc_extra</> is specified) NULL values
|
||||
and (if <literal>finalfunc_extra</> is specified) null values
|
||||
corresponding to the aggregated input(s). As with normal
|
||||
aggregates, <literal>finalfunc_extra</> is only really useful if the
|
||||
aggregate is polymorphic; then the extra dummy argument(s) are needed
|
||||
|
@ -568,7 +568,7 @@
|
||||
<row>
|
||||
<entry><function>consistent</></entry>
|
||||
<entry>
|
||||
determine whether value matches query condition (boolean variant)
|
||||
determine whether value matches query condition (Boolean variant)
|
||||
(optional if support function 6 is present)
|
||||
</entry>
|
||||
<entry>4</entry>
|
||||
|
@ -154,7 +154,7 @@
|
||||
</entry>
|
||||
<entry>
|
||||
<para>
|
||||
Like <function>xpath_nodeset(document, query, toptag, itemtag)</> but result omits toptag.
|
||||
Like <function>xpath_nodeset(document, query, toptag, itemtag)</> but result omits <literal>toptag</literal>.
|
||||
</para>
|
||||
</entry>
|
||||
</row>
|
||||
@ -460,7 +460,7 @@ xslt_process(text document, text stylesheet, text paramlist) returns text
|
||||
|
||||
<para>
|
||||
Development of this module was sponsored by Torchbox Ltd. (www.torchbox.com).
|
||||
It has the same BSD licence as PostgreSQL.
|
||||
It has the same BSD license as PostgreSQL.
|
||||
</para>
|
||||
</sect2>
|
||||
|
||||
|
Loading…
x
Reference in New Issue
Block a user