Documentation spell checking and markup improvements
This commit is contained in:
parent
81a4dcf2f2
commit
bbaf9e8f84
@ -152,7 +152,7 @@
|
||||
<entry><type>integer</type></entry>
|
||||
<entry>
|
||||
Alternate name for <function>pg_rotate_logfile()</>, but note that it
|
||||
returns integer 0 or 1 rather than boolean
|
||||
returns integer 0 or 1 rather than <type>boolean</type>
|
||||
</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
|
@ -215,7 +215,7 @@ ORDER BY c.relpages DESC LIMIT 10;
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Filesystem or storage subsystem faults where checksums happen to
|
||||
File system or storage subsystem faults where checksums happen to
|
||||
simply not be enabled.
|
||||
</para>
|
||||
<para>
|
||||
@ -223,7 +223,7 @@ ORDER BY c.relpages DESC LIMIT 10;
|
||||
shared memory buffer at the time of verification if there is only a
|
||||
shared buffer hit when accessing the block. Consequently,
|
||||
<filename>amcheck</> does not necessarily examine data read from the
|
||||
filesystem at the time of verification. Note that when checksums are
|
||||
file system at the time of verification. Note that when checksums are
|
||||
enabled, <filename>amcheck</> may raise an error due to a checksum
|
||||
failure when a corrupt block is read into a buffer.
|
||||
</para>
|
||||
|
@ -1908,10 +1908,10 @@ include_dir 'conf.d'
|
||||
<listitem>
|
||||
<para>
|
||||
Whenever more than <varname>bgwriter_flush_after</varname> bytes have
|
||||
been written by the bgwriter, attempt to force the OS to issue these
|
||||
been written by the background writer, attempt to force the OS to issue these
|
||||
writes to the underlying storage. Doing so will limit the amount of
|
||||
dirty data in the kernel's page cache, reducing the likelihood of
|
||||
stalls when an fsync is issued at the end of a checkpoint, or when
|
||||
stalls when an <function>fsync</function> is issued at the end of a checkpoint, or when
|
||||
the OS writes data back in larger batches in the background. Often
|
||||
that will result in greatly reduced transaction latency, but there
|
||||
also are some cases, especially with workloads that are bigger than
|
||||
@ -2029,7 +2029,7 @@ include_dir 'conf.d'
|
||||
pool of processes established by
|
||||
<xref linkend="guc-max-worker-processes">, limited by
|
||||
<xref linkend="guc-max-parallel-workers">. Note that the requested
|
||||
number of workers may not actually be available at runtime. If this
|
||||
number of workers may not actually be available at run time. If this
|
||||
occurs, the plan will run with fewer workers than expected, which may
|
||||
be inefficient. The default value is 2. Setting this value to 0
|
||||
disables parallel query execution.
|
||||
@ -2090,7 +2090,7 @@ include_dir 'conf.d'
|
||||
been written by a single backend, attempt to force the OS to issue
|
||||
these writes to the underlying storage. Doing so will limit the
|
||||
amount of dirty data in the kernel's page cache, reducing the
|
||||
likelihood of stalls when an fsync is issued at the end of a
|
||||
likelihood of stalls when an <function>fsync</function> is issued at the end of a
|
||||
checkpoint, or when the OS writes data back in larger batches in the
|
||||
background. Often that will result in greatly reduced transaction
|
||||
latency, but there also are some cases, especially with workloads
|
||||
@ -2270,7 +2270,7 @@ include_dir 'conf.d'
|
||||
For reliable recovery when changing <varname>fsync</varname>
|
||||
off to on, it is necessary to force all modified buffers in the
|
||||
kernel to durable storage. This can be done while the cluster
|
||||
is shutdown or while fsync is on by running <command>initdb
|
||||
is shutdown or while <varname>fsync</varname> is on by running <command>initdb
|
||||
--sync-only</command>, running <command>sync</>, unmounting the
|
||||
file system, or rebooting the server.
|
||||
</para>
|
||||
@ -2700,7 +2700,7 @@ include_dir 'conf.d'
|
||||
have been written while performing a checkpoint, attempt to force the
|
||||
OS to issue these writes to the underlying storage. Doing so will
|
||||
limit the amount of dirty data in the kernel's page cache, reducing
|
||||
the likelihood of stalls when an fsync is issued at the end of the
|
||||
the likelihood of stalls when an <function>fsync</function> is issued at the end of the
|
||||
checkpoint, or when the OS writes data back in larger batches in the
|
||||
background. Often that will result in greatly reduced transaction
|
||||
latency, but there also are some cases, especially with workloads
|
||||
@ -3460,7 +3460,7 @@ ANY <replaceable class="parameter">num_sync</replaceable> ( <replaceable class="
|
||||
<listitem>
|
||||
<para>
|
||||
Maximum number of synchronization workers per subscription. This
|
||||
parameter controls the amount of paralelism of the initial data copy
|
||||
parameter controls the amount of parallelism of the initial data copy
|
||||
during the subscription initialization or when new tables are added.
|
||||
</para>
|
||||
<para>
|
||||
@ -7356,7 +7356,7 @@ dynamic_library_path = 'C:\tools\postgresql;H:\my_project\lib;$libdir'
|
||||
limit, while negative values
|
||||
mean <xref linkend="guc-max-pred-locks-per-transaction"> divided by
|
||||
the absolute value of this setting. The default is -2, which keeps
|
||||
the behaviour from previous versions of <productname>PostgreSQL</>.
|
||||
the behavior from previous versions of <productname>PostgreSQL</>.
|
||||
This parameter can only be set in the <filename>postgresql.conf</>
|
||||
file or on the server command line.
|
||||
</para>
|
||||
|
@ -1769,13 +1769,13 @@ UPDATE 1
|
||||
<para>
|
||||
All of the policies constructed thus far have been permissive policies,
|
||||
meaning that when multiple policies are applied they are combined using
|
||||
the "OR" boolean operator. While permissive policies can be constructed
|
||||
the <quote>OR</quote> Boolean operator. While permissive policies can be constructed
|
||||
to only allow access to rows in the intended cases, it can be simpler to
|
||||
combine permissive policies with restrictive policies (which the records
|
||||
must pass and which are combined using the "AND" boolean operator).
|
||||
must pass and which are combined using the <quote>AND</quote> Boolean operator).
|
||||
Building on the example above, we add a restrictive policy to require
|
||||
the administrator to be connected over a local unix socket to access the
|
||||
records of the passwd table:
|
||||
the administrator to be connected over a local Unix socket to access the
|
||||
records of the <literal>passwd</literal> table:
|
||||
</para>
|
||||
|
||||
<programlisting>
|
||||
@ -2971,7 +2971,8 @@ VALUES ('Albany', NULL, NULL, 'NY');
|
||||
<command>CREATE TABLE</> nor is it possible to add columns to
|
||||
partitions after-the-fact using <command>ALTER TABLE</>. Tables may be
|
||||
added as a partition with <command>ALTER TABLE ... ATTACH PARTITION</>
|
||||
only if their columns exactly match the parent, including oids.
|
||||
only if their columns exactly match the parent, including any
|
||||
<literal>oid</literal> column.
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
|
@ -1207,7 +1207,7 @@ include $(PGXS)
|
||||
<term><varname>NO_INSTALLCHECK</varname></term>
|
||||
<listitem>
|
||||
<para>
|
||||
don't define an installcheck target, useful e.g. if tests require special configuration, or don't use pg_regress
|
||||
don't define an <literal>installcheck</literal> target, useful e.g. if tests require special configuration, or don't use <application>pg_regress</application>
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
@ -1302,7 +1302,7 @@
|
||||
transformation functions <literal><function>radians()</function></literal>
|
||||
and <literal><function>degrees()</function></literal> shown earlier.
|
||||
However, using the degree-based trigonometric functions is preferred,
|
||||
as that way avoids roundoff error for special cases such
|
||||
as that way avoids round-off error for special cases such
|
||||
as <literal>sind(30)</>.
|
||||
</para>
|
||||
</note>
|
||||
@ -9571,7 +9571,7 @@ CREATE TYPE rainbow AS ENUM ('red', 'orange', 'yellow', 'green', 'blue', 'purple
|
||||
<entry><type>tsvector</type></entry>
|
||||
<entry>
|
||||
reduce each string value in the document to a <type>tsvector</>, and then
|
||||
concatentate those in document order to produce a single <type>tsvector</>
|
||||
concatenate those in document order to produce a single <type>tsvector</>
|
||||
</entry>
|
||||
<entry><literal>to_tsvector('english', '{"a": "The Fat Rats"}'::json)</literal></entry>
|
||||
<entry><literal>'fat':2 'rat':3</literal></entry>
|
||||
@ -9744,7 +9744,7 @@ CREATE TYPE rainbow AS ENUM ('red', 'orange', 'yellow', 'green', 'blue', 'purple
|
||||
<literal><function>unnest(<type>tsvector</>, OUT <replaceable class="PARAMETER">lexeme</> <type>text</>, OUT <replaceable class="PARAMETER">positions</> <type>smallint[]</>, OUT <replaceable class="PARAMETER">weights</> <type>text</>)</function></literal>
|
||||
</entry>
|
||||
<entry><type>setof record</type></entry>
|
||||
<entry>expand a tsvector to a set of rows</entry>
|
||||
<entry>expand a <type>tsvector</type> to a set of rows</entry>
|
||||
<entry><literal>unnest('fat:2,4 cat:3 rat:5A'::tsvector)</literal></entry>
|
||||
<entry><literal>(cat,{3},{D}) ...</literal></entry>
|
||||
</row>
|
||||
@ -17675,7 +17675,7 @@ SELECT collation for ('foo' COLLATE "de_DE");
|
||||
<row>
|
||||
<entry><literal><function>txid_current_if_assigned()</function></literal></entry>
|
||||
<entry><type>bigint</type></entry>
|
||||
<entry>same as <function>txid_current()</function> but returns null instead of assigning an xid if none is already assigned</entry>
|
||||
<entry>same as <function>txid_current()</function> but returns null instead of assigning a new transaction ID if none is already assigned</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><literal><function>txid_current_snapshot()</function></literal></entry>
|
||||
@ -17705,7 +17705,7 @@ SELECT collation for ('foo' COLLATE "de_DE");
|
||||
<row>
|
||||
<entry><literal><function>txid_status(<parameter>bigint</parameter>)</function></literal></entry>
|
||||
<entry><type>txid_status</type></entry>
|
||||
<entry>report the status of the given xact - <literal>committed</literal>, <literal>aborted</literal>, <literal>in progress</literal>, or NULL if the txid is too old</entry>
|
||||
<entry>report the status of the given transaction: <literal>committed</literal>, <literal>aborted</literal>, <literal>in progress</literal>, or null if the transaction ID is too old</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
@ -18592,7 +18592,7 @@ postgres=# select pg_start_backup('label_goes_here');
|
||||
the <filename>backup_label</> and <filename>tablespace_map</> are returned
|
||||
in the result of the function, and should be written to files in the
|
||||
backup (and not in the data directory). There is an optional second
|
||||
parameter of type boolean. If false, the <function>pg_stop_backup</>
|
||||
parameter of type <type>boolean</type>. If false, the <function>pg_stop_backup</>
|
||||
will return immediately after the backup is completed without waiting for
|
||||
WAL to be archived. This behavior is only useful for backup
|
||||
software which independently monitors WAL archiving. Otherwise, WAL
|
||||
|
@ -35,7 +35,7 @@
|
||||
— register a buffer to be modified within the current generic WAL
|
||||
record. This function returns a pointer to a temporary copy of the
|
||||
buffer's page, where modifications should be made. (Do not modify the
|
||||
buffer's contents directly.) The third argument is a bitmask of flags
|
||||
buffer's contents directly.) The third argument is a bit mask of flags
|
||||
applicable to the operation. Currently the only such flag is
|
||||
<literal>GENERIC_XLOG_FULL_IMAGE</>, which indicates that a full-page
|
||||
image rather than a delta update should be included in the WAL record.
|
||||
|
@ -594,7 +594,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
|
||||
scans every page in the table that is not already all-frozen, it should
|
||||
set <literal>age(relfrozenxid)</> to a value just a little more than the
|
||||
<varname>vacuum_freeze_min_age</> setting
|
||||
that was used (more by the number of transcations started since the
|
||||
that was used (more by the number of transactions started since the
|
||||
<command>VACUUM</> started). If no <structfield>relfrozenxid</>-advancing
|
||||
<command>VACUUM</> is issued on the table until
|
||||
<varname>autovacuum_freeze_max_age</> is reached, an autovacuum will soon
|
||||
|
@ -1143,7 +1143,7 @@ postgres 27093 0.0 0.0 30096 2752 ? Ss 11:34 0:00 postgres: ser
|
||||
</row>
|
||||
<row>
|
||||
<entry><literal>userlock</></entry>
|
||||
<entry>Waiting to acquire a userlock.</entry>
|
||||
<entry>Waiting to acquire a user lock.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><literal>advisory</></entry>
|
||||
@ -1244,7 +1244,7 @@ postgres 27093 0.0 0.0 30096 2752 ? Ss 11:34 0:00 postgres: ser
|
||||
</row>
|
||||
<row>
|
||||
<entry><literal>BtreePage</></entry>
|
||||
<entry>Waiting for the page number needed to continue a parallel btree scan to become available.</entry>
|
||||
<entry>Waiting for the page number needed to continue a parallel B-tree scan to become available.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><literal>ExecuteGather</></entry>
|
||||
|
@ -1214,7 +1214,7 @@ SELECT * FROM zipcodes WHERE city = 'San Francisco' AND zip = '90210';
|
||||
<para>
|
||||
In many practical situations, this assumption is usually satisfied;
|
||||
for example, there might be a GUI in the application that only allows
|
||||
selecting compatible city and zipcode values to use in a query.
|
||||
selecting compatible city and ZIP code values to use in a query.
|
||||
But if that's not the case, functional dependencies may not be a viable
|
||||
option.
|
||||
</para>
|
||||
|
@ -1335,7 +1335,7 @@ DO 'elog(WARNING, join ", ", sort keys %INC)' LANGUAGE plperl;
|
||||
</programlisting>
|
||||
</para>
|
||||
<para>
|
||||
Initialization will happen in the postmaster if the plperl library is
|
||||
Initialization will happen in the postmaster if the <literal>plperl</literal> library is
|
||||
included in <xref linkend="guc-shared-preload-libraries">, in which
|
||||
case extra consideration should be given to the risk of destabilizing
|
||||
the postmaster. The principal reason for making use of this feature
|
||||
|
@ -882,7 +882,7 @@ CREATE EVENT TRIGGER tcl_a_snitch ON ddl_command_start EXECUTE PROCEDURE tclsnit
|
||||
first word identifies the subsystem or library reporting the error;
|
||||
beyond that the contents are left to the individual subsystem or
|
||||
library. For database errors reported by PL/Tcl commands, the first
|
||||
word is <literal>POSTGRES</literal>, the second word is the Postgres
|
||||
word is <literal>POSTGRES</literal>, the second word is the PostgreSQL
|
||||
version number, and additional words are field name/value pairs
|
||||
providing detailed information about the error.
|
||||
Fields <varname>SQLSTATE</>, <varname>condition</>,
|
||||
|
@ -126,7 +126,7 @@ CREATE POLICY <replaceable class="parameter">name</replaceable> ON <replaceable
|
||||
<para>
|
||||
Specify that the policy is to be created as a permissive policy.
|
||||
All permissive policies which are applicable to a given query will
|
||||
be combined together using the boolean "OR" operator. By creating
|
||||
be combined together using the Boolean <quote>OR</quote> operator. By creating
|
||||
permissive policies, administrators can add to the set of records
|
||||
which can be accessed. Policies are permissive by default.
|
||||
</para>
|
||||
@ -139,7 +139,7 @@ CREATE POLICY <replaceable class="parameter">name</replaceable> ON <replaceable
|
||||
<para>
|
||||
Specify that the policy is to be created as a restrictive policy.
|
||||
All restrictive policies which are applicable to a given query will
|
||||
be combined together using the boolean "AND" operator. By creating
|
||||
be combined together using the Boolean <quote>AND</quote> operator. By creating
|
||||
restrictive policies, administrators can reduce the set of records
|
||||
which can be accessed as all restrictive policies must be passed for
|
||||
each record.
|
||||
|
@ -152,14 +152,14 @@ CREATE STATISTICS s1 (dependencies) ON a, b FROM t1;
|
||||
|
||||
ANALYZE t1;
|
||||
|
||||
-- now the rowcount estimate is more accurate:
|
||||
-- now the row count estimate is more accurate:
|
||||
EXPLAIN ANALYZE SELECT * FROM t1 WHERE (a = 1) AND (b = 0);
|
||||
</programlisting>
|
||||
|
||||
Without functional-dependency statistics, the planner would assume
|
||||
that the two <literal>WHERE</> conditions are independent, and would
|
||||
multiply their selectivities together to arrive at a much-too-small
|
||||
rowcount estimate.
|
||||
row count estimate.
|
||||
With such statistics, the planner recognizes that the <literal>WHERE</>
|
||||
conditions are redundant and does not underestimate the rowcount.
|
||||
</para>
|
||||
|
@ -443,8 +443,8 @@ FROM ( { <replaceable class="PARAMETER">numeric_literal</replaceable> | <replace
|
||||
include multiple columns or expressions (up to 32, but this limit can
|
||||
altered when building <productname>PostgreSQL</productname>.), but for
|
||||
list partitioning, the partition key must consist of a single column or
|
||||
expression. If no btree operator class is specified when creating a
|
||||
partitioned table, the default btree operator class for the datatype will
|
||||
expression. If no B-tree operator class is specified when creating a
|
||||
partitioned table, the default B-tree operator class for the datatype will
|
||||
be used. If there is none, an error will be reported.
|
||||
</para>
|
||||
|
||||
|
@ -201,7 +201,7 @@ ROLLBACK;
|
||||
<term><literal>SUMMARY</literal></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Include summary information (eg: totalled timing information) after the
|
||||
Include summary information (e.g., totaled timing information) after the
|
||||
query plan. Summary information is included by default when
|
||||
<literal>ANALYZE</literal> is used but otherwise is not included by
|
||||
default, but can be enabled using this option. Planning time in
|
||||
|
@ -345,11 +345,14 @@ PostgreSQL documentation
|
||||
<term><option>--no-role-passwords</option></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Do not dump passwords for roles. When restored, roles will have a NULL
|
||||
password and authentication will always fail until the password is reset.
|
||||
Since password values aren't needed when this option is specified we
|
||||
use the catalog view pg_roles in preference to pg_authid, since access
|
||||
to pg_authid may be restricted by security policy.
|
||||
Do not dump passwords for roles. When restored, roles will have a
|
||||
null password, and password authentication will always fail until the
|
||||
password is set. Since password values aren't needed when this option
|
||||
is specified, the role information is read from the catalog
|
||||
view <structname>pg_roles</structname> instead
|
||||
of <structname>pg_authid</structname>. Therefore, this option also
|
||||
helps if access to <structname>pg_authid</structname> is restricted by
|
||||
some security policy.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
@ -52,7 +52,7 @@
|
||||
-->
|
||||
<para>
|
||||
<application>pg_upgrade</>-ed hash indexes from previous major
|
||||
Postgres versions must be rebuilt.
|
||||
PostgreSQL versions must be rebuilt.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@ -277,7 +277,7 @@
|
||||
Changing this from the default value caused queries referencing
|
||||
parent tables to not include children tables. The <acronym>SQL</>
|
||||
standard requires such behavior and this has been the default since
|
||||
Postgres 7.1.
|
||||
PostgreSQL 7.1.
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
@ -308,7 +308,7 @@
|
||||
|
||||
<para>
|
||||
Users needing dump support for pre-8.0 servers need to use dump
|
||||
binaries from Postgres 9.6.
|
||||
binaries from PostgreSQL 9.6.
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
@ -323,7 +323,7 @@
|
||||
<para>
|
||||
This removes configure's <option>--disable-integer-datetimes</>
|
||||
option. Floating-point datetimes/timestamps have not been the
|
||||
default since Postgres 8.3 and have few advantages.
|
||||
default since PostgreSQL 8.3 and have few advantages.
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
@ -336,7 +336,7 @@
|
||||
</para>
|
||||
|
||||
<para>
|
||||
This protocol hasn't had client support since Postgres 6.3.
|
||||
This protocol hasn't had client support since PostgreSQL 6.3.
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
@ -350,7 +350,7 @@
|
||||
|
||||
<para>
|
||||
This removes compatibility with the contrib version of full text
|
||||
search that shipped in pre-8.3 Postgres versions.
|
||||
search that shipped in pre-8.3 PostgreSQL versions.
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
@ -412,12 +412,12 @@
|
||||
2017-02-19 [0414b26ba] Add optimizer and executor support for parallel index-on
|
||||
-->
|
||||
<para>
|
||||
Support parallel btree index scans (Rahila Syed, Amit Kapila,
|
||||
Support parallel B-tree index scans (Rahila Syed, Amit Kapila,
|
||||
Robert Haas, Rafia Sabih)
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Allows btree index pages to be checked by separate parallel
|
||||
Allows B-tree index pages to be checked by separate parallel
|
||||
workers.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -735,7 +735,7 @@
|
||||
2017-01-15 [0777f7a2e] Fix matching of boolean index columns to sort ordering.
|
||||
-->
|
||||
<para>
|
||||
Improve planner matching of boolean indexes (Tom Lane)
|
||||
Improve planner matching of <type>boolean</type> indexes (Tom Lane)
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
@ -824,7 +824,7 @@
|
||||
2017-03-29 [f90d23d0c] Implement SortSupport for macaddr data type
|
||||
-->
|
||||
<para>
|
||||
Improve sort performance of the macaddr data type (Brandur Leach)
|
||||
Improve sort performance of the <type>macaddr</type> data type (Brandur Leach)
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
@ -1217,7 +1217,7 @@
|
||||
2017-04-05 [68ea2b7f9] Reduce lock level for CREATE STATISTICS
|
||||
-->
|
||||
<para>
|
||||
Reduce locking required to change table params (Simon Riggs,
|
||||
Reduce locking required to change table parameters (Simon Riggs,
|
||||
Fabrízio Mello)
|
||||
</para>
|
||||
|
||||
@ -1337,7 +1337,7 @@
|
||||
|
||||
<para>
|
||||
This allows more fine-grained replication options, including
|
||||
replication between different major versions of Postgres and
|
||||
replication between different major versions of PostgreSQL and
|
||||
selective-table replication.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -2127,7 +2127,7 @@
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The ecpg version now matches the Postgres distribution version
|
||||
The ecpg version now matches the PostgreSQL distribution version
|
||||
number.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -2427,7 +2427,7 @@
|
||||
|
||||
<para>
|
||||
Temporary replication slots will be used by default when
|
||||
<application>pg_basebackup</> uses wal streaming with default
|
||||
<application>pg_basebackup</> uses WAL streaming with default
|
||||
options.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -2525,7 +2525,7 @@
|
||||
<para>
|
||||
Major versions will now increase just the first number, and minor
|
||||
releases will increase just the second number. A third number
|
||||
will no longer be used in Postgres version numbers.
|
||||
will no longer be used in PostgreSQL version numbers.
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
@ -2670,7 +2670,7 @@
|
||||
2017-04-06 [510074f9f] Remove use of Jade and DSSSL
|
||||
-->
|
||||
<para>
|
||||
Use <acronym>XSLT</> to build the Postgres documentation (Peter
|
||||
Use <acronym>XSLT</> to build the PostgreSQL documentation (Peter
|
||||
Eisentraut)
|
||||
</para>
|
||||
|
||||
@ -2785,7 +2785,7 @@
|
||||
-->
|
||||
<para>
|
||||
Add <link linkend="amcheck"><application>amcheck</></> which can
|
||||
check the validity of btree indexes (Peter Geoghegan)
|
||||
check the validity of B-tree indexes (Peter Geoghegan)
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
|
@ -527,7 +527,7 @@ DROP ROLE doomed_role;
|
||||
</row>
|
||||
<row>
|
||||
<entry>pg_stat_scan_tables</entry>
|
||||
<entry>Execute monitoring functions that may take AccessShareLocks on tables,
|
||||
<entry>Execute monitoring functions that may take <literal>ACCESS SHARE</literal> locks on tables,
|
||||
potentially for a long time.</entry>
|
||||
</row>
|
||||
<row>
|
||||
|
@ -2354,7 +2354,7 @@ CREATE FUNCTION concat_text(text, text) RETURNS text
|
||||
the system should automatically assume a null result if any input
|
||||
value is null. By doing this, we avoid having to check for null inputs
|
||||
in the function code. Without this, we'd have to check for null values
|
||||
explicitly, using PG_ARGISNULL().
|
||||
explicitly, using <function>PG_ARGISNULL()</function>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@ -3086,7 +3086,7 @@ CREATE OR REPLACE FUNCTION retcomposite(IN integer, IN integer,
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The directory <link linkend="tablefunc">contrib/tablefunc</>
|
||||
The directory <link linkend="tablefunc"><filename>contrib/tablefunc</filename></>
|
||||
module in the source distribution contains more examples of
|
||||
set-returning functions.
|
||||
</para>
|
||||
|
Loading…
x
Reference in New Issue
Block a user