mirror of
https://github.com/postgres/postgres.git
synced 2025-06-08 22:02:03 +03:00
doc: Spell checking
This commit is contained in:
parent
87efbc2be1
commit
103ef20211
@ -40,7 +40,7 @@ pg_dump <replaceable class="parameter">dbname</replaceable> > <replaceable cl
|
||||
As you see, <application>pg_dump</> writes its result to the
|
||||
standard output. We will see below how this can be useful.
|
||||
While the above command creates a text file, <application>pg_dump</>
|
||||
can create files in other formats that allow for parallism and more
|
||||
can create files in other formats that allow for parallelism and more
|
||||
fine-grained control of object restoration.
|
||||
</para>
|
||||
|
||||
@ -221,7 +221,7 @@ psql -f <replaceable class="parameter">infile</replaceable> postgres
|
||||
roles, tablespaces, and empty databases, then invoking
|
||||
<application>pg_dump</> for each database. This means that while
|
||||
each database will be internally consistent, the snapshots of
|
||||
different databases are not sychronized.
|
||||
different databases are not synchronized.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
@ -532,7 +532,7 @@ typedef struct BrinOpcInfo
|
||||
The core distribution includes support for two types of operator classes:
|
||||
minmax and inclusion. Operator class definitions using them are shipped for
|
||||
in-core data types as appropriate. Additional operator classes can be
|
||||
defined by the user for other datatypes using equivalent definitions,
|
||||
defined by the user for other data types using equivalent definitions,
|
||||
without having to write any source code; appropriate catalog entries being
|
||||
declared is enough. Note that assumptions about the semantics of operator
|
||||
strategies are embedded in the support procedures's source code.
|
||||
@ -547,8 +547,8 @@ typedef struct BrinOpcInfo
|
||||
</para>
|
||||
|
||||
<para>
|
||||
To write an operator class for a datatype that implements a totally
|
||||
ordered set, it is possible to use the Minmax support procedures
|
||||
To write an operator class for a data type that implements a totally
|
||||
ordered set, it is possible to use the minmax support procedures
|
||||
alongside the corresponding operators, as shown in
|
||||
<xref linkend="brin-extensibility-minmax-table">.
|
||||
All operator class members (procedures and operators) are mandatory.
|
||||
|
@ -7946,7 +7946,7 @@
|
||||
<row>
|
||||
<entry><structfield>sourcefile</structfield></entry>
|
||||
<entry><structfield>text</structfield></entry>
|
||||
<entry>Full pathname of the configuration file</entry>
|
||||
<entry>Full path name of the configuration file</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><structfield>sourceline</structfield></entry>
|
||||
|
@ -958,11 +958,11 @@ omicron bryanh guest1
|
||||
<productname>PostgreSQL</> also supports a parameter to strip the realm from
|
||||
the principal. This method is supported for backwards compatibility and is
|
||||
strongly discouraged as it is then impossible to distinguish different users
|
||||
with the same username but coming from different realms. To enable this,
|
||||
with the same user name but coming from different realms. To enable this,
|
||||
set <literal>include_realm</> to 0. For simple single-realm
|
||||
installations, <literal>include_realm</> combined with the
|
||||
<literal>krb_realm</> parameter (which checks that the realm provided
|
||||
matches exactly what is in the krb_realm parameter) would be a secure but
|
||||
matches exactly what is in the <literal>krb_realm</literal> parameter) would be a secure but
|
||||
less capable option compared to specifying an explicit mapping in
|
||||
<filename>pg_ident.conf</>.
|
||||
</para>
|
||||
@ -1009,8 +1009,8 @@ omicron bryanh guest1
|
||||
If set to 0, the realm name from the authenticated user principal is
|
||||
stripped off before being passed through the user name mapping
|
||||
(<xref linkend="auth-username-maps">). This is discouraged and is
|
||||
primairly available for backwards compatibility as it is not secure
|
||||
in multi-realm environments unless krb_realm is also used. Users
|
||||
primarily available for backwards compatibility as it is not secure
|
||||
in multi-realm environments unless <literal>krb_realm</literal> is also used. Users
|
||||
are recommended to leave include_realm set to the default (1) and to
|
||||
provide an explicit mapping in <filename>pg_ident.conf</>.
|
||||
</para>
|
||||
@ -1030,7 +1030,7 @@ omicron bryanh guest1
|
||||
<literal>username/hostbased@EXAMPLE.COM</literal>, respectively),
|
||||
unless <literal>include_realm</literal> has been set to 0, in which case
|
||||
<literal>username</literal> (or <literal>username/hostbased</literal>)
|
||||
is what is seen as the system username when mapping.
|
||||
is what is seen as the system user name when mapping.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -1088,8 +1088,8 @@ omicron bryanh guest1
|
||||
If set to 0, the realm name from the authenticated user principal is
|
||||
stripped off before being passed through the user name mapping
|
||||
(<xref linkend="auth-username-maps">). This is discouraged and is
|
||||
primairly available for backwards compatibility as it is not secure
|
||||
in multi-realm environments unless krb_realm is also used. Users
|
||||
primarily available for backwards compatibility as it is not secure
|
||||
in multi-realm environments unless <literal>krb_realm</literal> is also used. Users
|
||||
are recommended to leave include_realm set to the default (1) and to
|
||||
provide an explicit mapping in <filename>pg_ident.conf</>.
|
||||
</para>
|
||||
@ -1109,7 +1109,7 @@ omicron bryanh guest1
|
||||
<literal>username/hostbased@EXAMPLE.COM</literal>, respectively),
|
||||
unless <literal>include_realm</literal> has been set to 0, in which case
|
||||
<literal>username</literal> (or <literal>username/hostbased</literal>)
|
||||
is what is seen as the system username when mapping.
|
||||
is what is seen as the system user name when mapping.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -1292,7 +1292,7 @@ omicron bryanh guest1
|
||||
this search, the server disconnects and re-binds to the directory as
|
||||
this user, using the password specified by the client, to verify that the
|
||||
login is correct. This mode is the same as that used by LDAP authentication
|
||||
schemes in other software, such as Apache mod_authnz_ldap and pam_ldap.
|
||||
schemes in other software, such as Apache <literal>mod_authnz_ldap</literal> and <literal>pam_ldap</literal>.
|
||||
This method allows for significantly more flexibility
|
||||
in where the user objects are located in the directory, but will cause
|
||||
two separate connections to the LDAP server to be made.
|
||||
|
@ -1902,7 +1902,7 @@ include_dir 'conf.d'
|
||||
|
||||
<para>
|
||||
The default is 1 on supported systems, otherwise 0. This value can
|
||||
be overriden for tables in a particular tablespace by setting the
|
||||
be overridden for tables in a particular tablespace by setting the
|
||||
tablespace parameter of the same name (see
|
||||
<xref linkend="sql-altertablespace">).
|
||||
</para>
|
||||
@ -1993,7 +1993,7 @@ include_dir 'conf.d'
|
||||
<para>
|
||||
In <literal>logical</> level, the same information is logged as
|
||||
with <literal>hot_standby</>, plus information needed to allow
|
||||
extracting logical changesets from the WAL. Using a level of
|
||||
extracting logical change sets from the WAL. Using a level of
|
||||
<literal>logical</> will increase the WAL volume, particularly if many
|
||||
tables are configured for <literal>REPLICA IDENTITY FULL</literal> and
|
||||
many <command>UPDATE</> and <command>DELETE</> statements are
|
||||
@ -3909,7 +3909,7 @@ local0.* /var/log/postgresql
|
||||
listed in the Open Group's <ulink
|
||||
url="http://pubs.opengroup.org/onlinepubs/009695399/functions/strftime.html">strftime
|
||||
</ulink> specification.
|
||||
Note that the system's <systemitem>strftime</systemitem> is not used
|
||||
Note that the system's <function>strftime</function> is not used
|
||||
directly, so platform-specific (nonstandard) extensions do not work.
|
||||
The default is <literal>postgresql-%Y-%m-%d_%H%M%S.log</literal>.
|
||||
</para>
|
||||
|
@ -70,7 +70,7 @@ typedef struct CustomPath
|
||||
<para>
|
||||
<structfield>path</> must be initialized as for any other path, including
|
||||
the row-count estimate, start and total cost, and sort ordering provided
|
||||
by this path. <structfield>flags</> is a bitmask, which should include
|
||||
by this path. <structfield>flags</> is a bit mask, which should include
|
||||
<literal>CUSTOMPATH_SUPPORT_BACKWARD_SCAN</> if the custom path can support
|
||||
a backward scan and <literal>CUSTOMPATH_SUPPORT_MARK_RESTORE</> if it
|
||||
can support mark and restore. Both capabilities are optional.
|
||||
@ -163,7 +163,7 @@ typedef struct CustomScan
|
||||
<para>
|
||||
<structfield>scan</> must be initialized as for any other scan, including
|
||||
estimated costs, target lists, qualifications, and so on.
|
||||
<structfield>flags</> is a bitmask with the same meaning as in
|
||||
<structfield>flags</> is a bit mask with the same meaning as in
|
||||
<structname>CustomPath</>.
|
||||
<structfield>custom_plans</> can be used to store child
|
||||
<structname>Plan</> nodes.
|
||||
@ -174,12 +174,12 @@ typedef struct CustomScan
|
||||
that is only used by the custom scan provider itself.
|
||||
<structfield>custom_scan_tlist</> can be NIL when scanning a base
|
||||
relation, indicating that the custom scan returns scan tuples that match
|
||||
the base relation's rowtype. Otherwise it is a targetlist describing
|
||||
the base relation's row type. Otherwise it is a target list describing
|
||||
the actual scan tuples. <structfield>custom_scan_tlist</> must be
|
||||
provided for joins, and could be provided for scans if the custom scan
|
||||
provider can compute some non-Var expressions.
|
||||
<structfield>custom_relids</> is set by the core code to the set of
|
||||
relations (rangetable indexes) that this scan node handles; except when
|
||||
relations (range table indexes) that this scan node handles; except when
|
||||
this scan is replacing a join, it will have only one member.
|
||||
<structfield>methods</> must point to a (usually statically allocated)
|
||||
object implementing the required custom scan methods, which are further
|
||||
@ -251,10 +251,10 @@ typedef struct CustomScanState
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<structfield>ss</> is initialized as for any other scanstate,
|
||||
<structfield>ss</> is initialized as for any other scan state,
|
||||
except that if the scan is for a join rather than a base relation,
|
||||
<literal>ss.ss_currentRelation</> is left NULL.
|
||||
<structfield>flags</> is a bitmask with the same meaning as in
|
||||
<structfield>flags</> is a bit mask with the same meaning as in
|
||||
<structname>CustomPath</> and <structname>CustomScan</>.
|
||||
<structfield>methods</> must point to a (usually statically allocated)
|
||||
object implementing the required custom scan state methods, which are
|
||||
|
@ -545,7 +545,7 @@ CREATE TABLE products (
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Adding a unique constraint will automatically create a unique btree
|
||||
Adding a unique constraint will automatically create a unique B-tree
|
||||
index on the column or group of columns used in the constraint.
|
||||
A uniqueness constraint on only some rows can be enforced by creating
|
||||
a <link linkend="indexes-partial">partial index</link>.
|
||||
@ -630,7 +630,7 @@ CREATE TABLE example (
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Adding a primary key will automatically create a unique btree index
|
||||
Adding a primary key will automatically create a unique B-tree index
|
||||
on the column or group of columns used in the primary key.
|
||||
</para>
|
||||
|
||||
@ -1559,7 +1559,7 @@ REVOKE ALL ON accounts FROM PUBLIC;
|
||||
<para>
|
||||
To specify which rows are visible and what rows can be added to the
|
||||
table with row level security, an expression is required which returns
|
||||
a boolean result. This expression will be evaluated for each row prior
|
||||
a Boolean result. This expression will be evaluated for each row prior
|
||||
to other conditionals or functions which are part of the query. The
|
||||
one exception to this rule are <literal>leakproof</literal> functions,
|
||||
which are guaranteed to not leak information. Two expressions may be
|
||||
@ -1676,7 +1676,7 @@ CREATE POLICY user_policy ON users
|
||||
|
||||
<para>
|
||||
Below is a larger example of how this feature can be used in
|
||||
production environments, based on a unix password file.
|
||||
production environments, based on a Unix password file.
|
||||
</para>
|
||||
|
||||
<programlisting>
|
||||
|
@ -239,7 +239,7 @@ IterateForeignScan (ForeignScanState *node);
|
||||
|
||||
<para>
|
||||
The rows returned must match the <structfield>fdw_scan_tlist</> target
|
||||
list if one was supplied, otherwise they must match the rowtype of the
|
||||
list if one was supplied, otherwise they must match the row type of the
|
||||
foreign table being scanned. If you choose to optimize away fetching
|
||||
columns that are not needed, you should insert nulls in those column
|
||||
positions, or else generate a <structfield>fdw_scan_tlist</> list with
|
||||
@ -333,7 +333,7 @@ GetForeignJoinPaths (PlannerInfo *root,
|
||||
remote join cannot be found from the system catalogs, the FDW must
|
||||
fill <structfield>fdw_scan_tlist</> with an appropriate list
|
||||
of <structfield>TargetEntry</> nodes, representing the set of columns
|
||||
it will supply at runtime in the tuples it returns.
|
||||
it will supply at run time in the tuples it returns.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@ -752,7 +752,7 @@ RefetchForeignRow (EState *estate,
|
||||
for the row to be re-fetched. Although the <literal>rowid</> value is
|
||||
passed as a <type>Datum</>, it can currently only be a <type>tid</>. The
|
||||
function API is chosen in hopes that it may be possible to allow other
|
||||
datatypes for row IDs in future.
|
||||
data types for row IDs in future.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@ -1140,8 +1140,8 @@ GetForeignServerByName(const char *name, bool missing_ok);
|
||||
is <structfield>fdw_scan_tlist</>, which describes the tuples returned by
|
||||
the FDW for this plan node. For simple foreign table scans this can be
|
||||
set to <literal>NIL</>, implying that the returned tuples have the
|
||||
rowtype declared for the foreign table. A non-NIL value must be a
|
||||
targetlist (list of <structname>TargetEntry</>s) containing Vars and/or
|
||||
row type declared for the foreign table. A non-<symbol>NIL</symbol> value must be a
|
||||
target list (list of <structname>TargetEntry</>s) containing Vars and/or
|
||||
expressions representing the returned columns. This might be used, for
|
||||
example, to show that the FDW has omitted some columns that it noticed
|
||||
won't be needed for the query. Also, if the FDW can compute expressions
|
||||
|
@ -10327,7 +10327,7 @@ table2-mapping
|
||||
<row>
|
||||
<entry><literal>||</literal></entry>
|
||||
<entry><type>jsonb</type></entry>
|
||||
<entry>Concatentate two jsonb values into a new jsonb value</entry>
|
||||
<entry>Concatenate two <type>jsonb</type> values into a new <type>jsonb</type> value</entry>
|
||||
<entry><literal>'["a", "b"]'::jsonb || '["c", "d"]'::jsonb</literal></entry>
|
||||
</row>
|
||||
<row>
|
||||
@ -10986,7 +10986,7 @@ table2-mapping
|
||||
If the argument to <literal>json_strip_nulls</> contains duplicate
|
||||
field names in any object, the result could be semantically somewhat
|
||||
different, depending on the order in which they occur. This is not an
|
||||
issue for <literal>jsonb_strip_nulls</> since jsonb values never have
|
||||
issue for <literal>jsonb_strip_nulls</> since <type>jsonb</type> values never have
|
||||
duplicate object field names.
|
||||
</para>
|
||||
</note>
|
||||
@ -13433,7 +13433,7 @@ SELECT xmlagg(x) FROM (SELECT x FROM test ORDER BY y DESC) AS tab;
|
||||
<type>integer</type>
|
||||
</entry>
|
||||
<entry>
|
||||
Integer bitmask indicating which arguments are not being included in the current
|
||||
Integer bit mask indicating which arguments are not being included in the current
|
||||
grouping set
|
||||
</entry>
|
||||
</row>
|
||||
@ -16633,7 +16633,7 @@ SELECT set_config('log_statement_stats', 'off', false);
|
||||
</entry>
|
||||
<entry><type>boolean</type></entry>
|
||||
<entry>Cancel a backend's current query. This is also allowed if the
|
||||
calling role is a member of the role whose backend is being cancelled,
|
||||
calling role is a member of the role whose backend is being canceled,
|
||||
however only superusers can cancel superuser backends.
|
||||
</entry>
|
||||
</row>
|
||||
@ -18600,7 +18600,7 @@ CREATE EVENT TRIGGER test_event_trigger_for_drops
|
||||
<literal><function>pg_event_trigger_table_rewrite_oid()</function></literal>
|
||||
</entry>
|
||||
<entry><type>Oid</type></entry>
|
||||
<entry>The Oid of the table about to be rewritten.</entry>
|
||||
<entry>The OID of the table about to be rewritten.</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
|
@ -343,7 +343,7 @@ SELECT * FROM places ORDER BY location <-> point '(101,456)' LIMIT 10;
|
||||
BRIN can support many different indexing strategies,
|
||||
and the particular operators with which a BRIN index can be used
|
||||
vary depending on the indexing strategy.
|
||||
For datatypes that have a linear sort order, the indexed data
|
||||
For data types that have a linear sort order, the indexed data
|
||||
corresponds to the minimum and maximum values of the
|
||||
values in the column for each block range,
|
||||
which support indexed queries using these operators:
|
||||
|
@ -139,7 +139,7 @@ PGconn *PQconnectdbParams(const char * const *keywords,
|
||||
</para>
|
||||
|
||||
<para>
|
||||
If any parameter is <symbol>NULL</symbol> or an emptry string, the corresponding
|
||||
If any parameter is <symbol>NULL</symbol> or an empty 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.
|
||||
@ -2014,7 +2014,7 @@ void *PQgetssl(const PGconn *conn);
|
||||
</para>
|
||||
|
||||
<para>
|
||||
This function is equivalent to PQsslStruct(conn, "OpenSSL"). It should
|
||||
This function is equivalent to <literal>PQsslStruct(conn, "OpenSSL")</literal>. It should
|
||||
not be used in new applications, because the returned struct is
|
||||
specific to OpenSSL and will not be available if another SSL
|
||||
implementation is used. To check if a connection uses SSL, call
|
||||
|
@ -577,7 +577,7 @@ typedef void (*LogicalDecodeChangeCB) (
|
||||
|
||||
<para>
|
||||
The optional <function>filter_by_origin_cb</function> callback
|
||||
is called to determine wheter data that has been replayed
|
||||
is called to determine whether data that has been replayed
|
||||
from <parameter>origin_id</parameter> is of interest to the
|
||||
output plugin.
|
||||
<programlisting>
|
||||
@ -594,7 +594,7 @@ typedef bool (*LogicalDecodeChangeCB) (
|
||||
for transactions and changes that have been filtered away.
|
||||
</para>
|
||||
<para>
|
||||
This is useful when implementing cascading or multi directional
|
||||
This is useful when implementing cascading or multidirectional
|
||||
replication solutions. Filtering by the origin allows to
|
||||
prevent replicating the same changes back and forth in such
|
||||
setups. While transactions and changes also carry information
|
||||
|
@ -661,7 +661,7 @@ HINT: Stop the postmaster and vacuum that database in single-user mode.
|
||||
<xref linkend="guc-autovacuum-multixact-freeze-max-age">. Whole-table
|
||||
vacuum scans will also occur progressively for all tables, starting with
|
||||
those that have the oldest multixact-age, if the amount of used member
|
||||
storage space exceeds the amount 50% of the addressible storage space.
|
||||
storage space exceeds the amount 50% of the addressable storage space.
|
||||
Both of these kinds of whole-table scans will occur even if autovacuum is
|
||||
nominally disabled.
|
||||
</para>
|
||||
@ -861,7 +861,7 @@ analyze threshold = analyze base threshold + analyze scale factor * number of tu
|
||||
and <xref linkend="sql-dropindex">. When an index is used to enforce
|
||||
uniqueness or other constraints, <xref linkend="sql-altertable"> might
|
||||
be necessary to swap the existing constraint with one enforced by
|
||||
the new index. Review this alternate multi-step rebuild approach
|
||||
the new index. Review this alternate multistep rebuild approach
|
||||
carefully before using it as there are limitations on which
|
||||
indexes can be reindexed this way, and errors must be handled.
|
||||
</para>
|
||||
|
@ -389,7 +389,7 @@ dropdb <replaceable class="parameter">dbname</replaceable>
|
||||
database cluster or backed up individually. Similarly, if you lose
|
||||
a tablespace (file deletion, disk failure, etc), the database cluster
|
||||
might become unreadable or unable to start. Placing a tablespace
|
||||
on a temporary file system like a ramdisk risks the reliability of
|
||||
on a temporary file system like a RAM disk risks the reliability of
|
||||
the entire cluster.
|
||||
</para>
|
||||
</warning>
|
||||
|
@ -3617,10 +3617,10 @@ RAISE unique_violation USING MESSAGE = 'Duplicate user ID: ' || user_id;
|
||||
ASSERT <replaceable class="parameter">condition</replaceable> <optional> , <replaceable class="parameter">message</replaceable> </optional>;
|
||||
</synopsis>
|
||||
|
||||
The <replaceable class="parameter">condition</replaceable> is a boolean
|
||||
expression that is expected to always evaluate to TRUE; if it does,
|
||||
The <replaceable class="parameter">condition</replaceable> is a Boolean
|
||||
expression that is expected to always evaluate to true; if it does,
|
||||
the <command>ASSERT</command> statement does nothing further. If the
|
||||
result is FALSE or NULL, then an <literal>ASSERT_FAILURE</> exception
|
||||
result is false or null, then an <literal>ASSERT_FAILURE</> exception
|
||||
is raised. (If an error occurs while evaluating
|
||||
the <replaceable class="parameter">condition</replaceable>, it is
|
||||
reported as a normal error.)
|
||||
@ -3637,7 +3637,7 @@ ASSERT <replaceable class="parameter">condition</replaceable> <optional> , <repl
|
||||
|
||||
<para>
|
||||
Testing of assertions can be enabled or disabled via the configuration
|
||||
parameter <literal>plpgsql.check_asserts</>, which takes a boolean
|
||||
parameter <literal>plpgsql.check_asserts</>, which takes a Boolean
|
||||
value; the default is <literal>on</>. If this parameter
|
||||
is <literal>off</> then <command>ASSERT</> statements do nothing.
|
||||
</para>
|
||||
|
@ -294,7 +294,7 @@
|
||||
<listitem>
|
||||
<para>
|
||||
The frontend must now send a PasswordMessage containing the
|
||||
password (with username) encrypted via MD5, then encrypted
|
||||
password (with user name) encrypted via MD5, then encrypted
|
||||
again using the 4-byte random salt specified in the
|
||||
AuthenticationMD5Password message. If this is the correct
|
||||
password, the server responds with an AuthenticationOk,
|
||||
|
@ -1236,7 +1236,7 @@ SELECT product_id, p.name, (sum(s.units) * (p.price - p.cost)) AS profit
|
||||
|
||||
<para>
|
||||
References to the grouping columns or expressions are replaced
|
||||
by <literal>NULL</> values in result rows for grouping sets in which those
|
||||
by null values in result rows for grouping sets in which those
|
||||
columns do not appear. To distinguish which grouping a particular output
|
||||
row resulted from, see <xref linkend="functions-grouping-table">.
|
||||
</para>
|
||||
@ -1289,8 +1289,8 @@ GROUPING SETS (
|
||||
|
||||
<para>
|
||||
The individual elements of a <literal>CUBE</> or <literal>ROLLUP</>
|
||||
clause may be either individual expressions, or sub-lists of elements in
|
||||
parentheses. In the latter case, the sub-lists are treated as single
|
||||
clause may be either individual expressions, or sublists of elements in
|
||||
parentheses. In the latter case, the sublists are treated as single
|
||||
units for the purposes of generating the individual grouping sets.
|
||||
For example:
|
||||
<programlisting>
|
||||
@ -2202,7 +2202,7 @@ SELECT n FROM t LIMIT 100;
|
||||
functions with side-effects.
|
||||
However, the other side of this coin is that the optimizer is less able to
|
||||
push restrictions from the parent query down into a <literal>WITH</> query
|
||||
than an ordinary sub-query. The <literal>WITH</> query will generally be
|
||||
than an ordinary subquery. The <literal>WITH</> query will generally be
|
||||
evaluated as written, without suppression of rows that the parent query
|
||||
might discard afterwards. (But, as mentioned above, evaluation might stop
|
||||
early if the reference(s) to the query demand only a limited number of
|
||||
|
@ -446,7 +446,7 @@ restore_command = 'copy "C:\\server\\archivedir\\%f" "%p"' # Windows
|
||||
<para>
|
||||
It is possible that the replication delay between servers exceeds the
|
||||
value of this parameter, in which case no delay is added.
|
||||
Note that the delay is calculated between the WAL timestamp as written
|
||||
Note that the delay is calculated between the WAL time stamp as written
|
||||
on master and the current time on the standby. Delays in transfer
|
||||
because of network lag or cascading replication configurations
|
||||
may reduce the actual wait time significantly. If the system
|
||||
|
@ -114,7 +114,7 @@ ALTER DATABASE <replaceable class="PARAMETER">name</replaceable> RESET ALL
|
||||
<term><replaceable class="parameter">istemplate</replaceable></term>
|
||||
<listitem>
|
||||
<para>
|
||||
If true, then this database can be cloned by any user with CREATEDB
|
||||
If true, then this database can be cloned by any user with <literal>CREATEDB</literal>
|
||||
privileges; if false, then only superusers or the owner of the
|
||||
database can clone it.
|
||||
</para>
|
||||
|
@ -1072,7 +1072,7 @@ ALTER TABLE distributors
|
||||
</para>
|
||||
|
||||
<para>
|
||||
To change an integer column containing UNIX timestamps to <type>timestamp
|
||||
To change an integer column containing Unix timestamps to <type>timestamp
|
||||
with time zone</type> via a <literal>USING</literal> clause:
|
||||
<programlisting>
|
||||
ALTER TABLE foo
|
||||
|
@ -134,7 +134,7 @@ COMMENT ON
|
||||
<listitem>
|
||||
<para>
|
||||
When creating a comment on a constraint on a table or a domain, these
|
||||
parameteres specify the name of the table or domain on which the
|
||||
parameters specify the name of the table or domain on which the
|
||||
constraint is defined.
|
||||
</para>
|
||||
</listitem>
|
||||
|
@ -153,7 +153,7 @@ CREATE DATABASE <replaceable class="PARAMETER">name</replaceable>
|
||||
<term><replaceable class="parameter">istemplate</replaceable></term>
|
||||
<listitem>
|
||||
<para>
|
||||
If true, then this database can be cloned by any user with CREATEDB
|
||||
If true, then this database can be cloned by any user with <literal>CREATEDB</literal>
|
||||
privileges; if false (the default), then only superusers or the owner
|
||||
of the database can clone it.
|
||||
</para>
|
||||
|
@ -209,8 +209,8 @@ INSERT INTO tab (domcol) VALUES ((SELECT domcol FROM tab WHERE false));
|
||||
|
||||
<para>
|
||||
It is very difficult to avoid such problems, because of SQL's general
|
||||
assumption that NULL is a valid value of every datatype. Best practice
|
||||
therefore is to design a domain's constraints so that NULL is allowed,
|
||||
assumption that a null value is a valid value of every data type. Best practice
|
||||
therefore is to design a domain's constraints so that a null value is allowed,
|
||||
and then to apply column <literal>NOT NULL</> constraints to columns of
|
||||
the domain type as needed, rather than directly to the domain type.
|
||||
</para>
|
||||
|
@ -359,7 +359,7 @@ CREATE [ OR REPLACE ] FUNCTION
|
||||
prevent the inadvertent exposure of data. Functions and operators
|
||||
marked as leakproof are assumed to be trustworthy, and may be executed
|
||||
before conditions from security policies and security barrier views.
|
||||
In addtion, functions which do not take arguments or which are not
|
||||
In addition, functions which do not take arguments or which are not
|
||||
passed any arguments from the security barrier view or table do not have
|
||||
to be marked as leakproof to be executed before security conditions. See
|
||||
<xref linkend="sql-createview"> and <xref linkend="rules-privileges">.
|
||||
|
@ -308,7 +308,7 @@ INSERT INTO <replaceable class="PARAMETER">table_name</replaceable> [ AS <replac
|
||||
class="PARAMETER">column_name_index</replaceable> or
|
||||
<replaceable class="PARAMETER">expression_index</replaceable> use a
|
||||
particular collation in order to be matched in the inference clause.
|
||||
Typically this is omitted, as collations usually do not affect wether or
|
||||
Typically this is omitted, as collations usually do not affect whether or
|
||||
not a constraint violation occurs. Follows <command>CREATE
|
||||
INDEX</command> format.
|
||||
</para>
|
||||
@ -661,7 +661,7 @@ INSERT INTO distributors (did, dname) VALUES (9, 'Antwerp Design')
|
||||
<literal>DO NOTHING</literal>. Example assumes a unique index has been
|
||||
defined that constrains values appearing in the
|
||||
<literal>did</literal> column on a subset of rows where the
|
||||
<literal>is_active</literal> boolean column evaluates to
|
||||
<literal>is_active</literal> Boolean column evaluates to
|
||||
<literal>true</literal>:
|
||||
<programlisting>
|
||||
-- This statement could infer a partial unique index on "did"
|
||||
|
@ -601,7 +601,7 @@ PostgreSQL documentation
|
||||
<para>
|
||||
Tablespaces will in plain format by default be backed up to the same path
|
||||
they have on the server, unless the
|
||||
option <replaceable>--tablespace-mapping</replaceable> is used. Without
|
||||
option <literal>--tablespace-mapping</literal> is used. Without
|
||||
this option, running a plain format base backup on the same host as the
|
||||
server will not work if tablespaces are in use, because the backup would
|
||||
have to be written to the same directory locations as the original
|
||||
@ -610,18 +610,18 @@ PostgreSQL documentation
|
||||
|
||||
<para>
|
||||
When tar format mode is used, it is the user's responsibility to unpack each
|
||||
tar file before starting postgres. If there are additional tablespaces, the
|
||||
tar file before starting the PostgreSQL server. If there are additional tablespaces, the
|
||||
tar files for them need to be unpacked in the correct locations. In this
|
||||
case the symbolic links for those tablespaces will be created by Postgres
|
||||
case the symbolic links for those tablespaces will be created by the server
|
||||
according to the contents of the <filename>tablespace_map</> file that is
|
||||
included in the <filename>base.tar</> file.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<application>pg_basebackup</application> works with servers of the same
|
||||
or an older major version, down to 9.1. However, WAL streaming mode (-X
|
||||
stream) only works with server version 9.3 and later, and tar format mode
|
||||
(--format=tar) of the current version only works with server version 9.5
|
||||
or an older major version, down to 9.1. However, WAL streaming mode (<literal>-X
|
||||
stream</literal>) only works with server version 9.3 and later, and tar format mode
|
||||
(<literal>--format=tar</literal>) of the current version only works with server version 9.5
|
||||
or later.
|
||||
</para>
|
||||
|
||||
|
@ -849,7 +849,7 @@ PostgreSQL documentation
|
||||
<term><option>--snapshot=<replaceable class="parameter">snapshotname</replaceable></option></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Use the specifed synchronized snapshot when making a dump of the
|
||||
Use the specified synchronized snapshot when making a dump of the
|
||||
database (see
|
||||
<xref linkend="functions-snapshot-synchronization-table"> for more
|
||||
details).
|
||||
|
@ -111,7 +111,7 @@ PostgreSQL documentation
|
||||
<listitem>
|
||||
<para>
|
||||
Write received and decoded transaction data into this
|
||||
file. Use <literal>-</> for stdout.
|
||||
file. Use <literal>-</> for <systemitem>stdout</systemitem>.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -244,7 +244,7 @@ PostgreSQL documentation
|
||||
<listitem>
|
||||
<para>
|
||||
The database to connect to. See the description of the actions for
|
||||
what this means in detail. This can be a libpq connection string;
|
||||
what this means in detail. This can be a <application>libpq</application> connection string;
|
||||
see <xref linkend="LIBPQ-CONNSTRING"> for more information. Defaults
|
||||
to user name.
|
||||
</para>
|
||||
@ -283,7 +283,7 @@ PostgreSQL documentation
|
||||
<term><option>--username=<replaceable>user</replaceable></option></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Username to connect as. Defaults to current operating system user
|
||||
User name to connect as. Defaults to current operating system user
|
||||
name.
|
||||
</para>
|
||||
</listitem>
|
||||
|
@ -217,8 +217,8 @@ PostgreSQL documentation
|
||||
</step>
|
||||
<step>
|
||||
<para>
|
||||
Copy all other files like clog, conf files etc. from the new cluster
|
||||
to old cluster. Everything except the relation files.
|
||||
Copy all other files such as <filename>clog</filename> and configuration files from the new cluster
|
||||
to the old cluster, everything except the relation files.
|
||||
</para>
|
||||
</step>
|
||||
<step>
|
||||
|
@ -174,7 +174,7 @@ PostgreSQL documentation
|
||||
<term><option>--xid=<replaceable>xid</replaceable></option></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Only display records marked with the given TransactionId.
|
||||
Only display records marked with the given transaction ID.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -219,7 +219,7 @@ PostgreSQL documentation
|
||||
<para>
|
||||
<application>pg_xlogdump</> cannot read WAL files with suffix
|
||||
<literal>.partial</>. If those files need to be read, <literal>.partial</>
|
||||
suffix needs to be removed from the filename.
|
||||
suffix needs to be removed from the file name.
|
||||
</para>
|
||||
</refsect1>
|
||||
|
||||
|
@ -45,7 +45,7 @@
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Typical output from pgbench looks like:
|
||||
Typical output from <application>pgbench</application> looks like:
|
||||
|
||||
<screen>
|
||||
transaction type: TPC-B (sort of)
|
||||
@ -544,7 +544,7 @@ pgbench <optional> <replaceable>options</> </optional> <replaceable>dbname</>
|
||||
<listitem>
|
||||
<para>
|
||||
Vacuum all four standard tables before running the test.
|
||||
With neither <option>-n</> nor <option>-v</>, pgbench will vacuum the
|
||||
With neither <option>-n</> nor <option>-v</>, <application>pgbench</application> will vacuum the
|
||||
<structname>pgbench_tellers</> and <structname>pgbench_branches</>
|
||||
tables, and will truncate <structname>pgbench_history</>.
|
||||
</para>
|
||||
@ -658,7 +658,7 @@ pgbench <optional> <replaceable>options</> </optional> <replaceable>dbname</>
|
||||
<title>Notes</title>
|
||||
|
||||
<refsect2>
|
||||
<title>What is the <quote>Transaction</> Actually Performed in pgbench?</title>
|
||||
<title>What is the <quote>Transaction</> Actually Performed in <application>pgbench</application>?</title>
|
||||
|
||||
<para>
|
||||
The default transaction script issues seven commands per transaction:
|
||||
@ -955,7 +955,7 @@ END;
|
||||
<application>pgbench</> writes the time taken by each transaction
|
||||
to a log file. The log file will be named
|
||||
<filename>pgbench_log.<replaceable>nnn</></filename>, where
|
||||
<replaceable>nnn</> is the PID of the pgbench process.
|
||||
<replaceable>nnn</> is the PID of the <application>pgbench</application> process.
|
||||
If the <option>-j</> option is 2 or higher, creating multiple worker
|
||||
threads, each will have its own log file. The first worker will use the
|
||||
same name for its log file as in the standard single worker case.
|
||||
@ -976,9 +976,9 @@ END;
|
||||
<replaceable>file_no</> identifies which script file was used
|
||||
(useful when multiple scripts were specified with <option>-f</>),
|
||||
and <replaceable>time_epoch</>/<replaceable>time_us</> are a
|
||||
UNIX epoch format timestamp and an offset
|
||||
Unix epoch format time stamp and an offset
|
||||
in microseconds (suitable for creating an ISO 8601
|
||||
timestamp with fractional seconds) showing when
|
||||
time stamp with fractional seconds) showing when
|
||||
the transaction completed.
|
||||
Field <replaceable>schedule_lag</> is the difference between the
|
||||
transaction's scheduled start time, and the time it actually started, in
|
||||
@ -1031,8 +1031,8 @@ END;
|
||||
<replaceable>interval_start</> <replaceable>num_of_transactions</> <replaceable>latency_sum</> <replaceable>latency_2_sum</> <replaceable>min_latency</> <replaceable>max_latency</> <optional><replaceable>lag_sum</> <replaceable>lag_2_sum</> <replaceable>min_lag</> <replaceable>max_lag</> <optional><replaceable>skipped_transactions</></optional></optional>
|
||||
</synopsis>
|
||||
|
||||
where <replaceable>interval_start</> is the start of the interval (UNIX epoch
|
||||
format timestamp), <replaceable>num_of_transactions</> is the number of transactions
|
||||
where <replaceable>interval_start</> is the start of the interval (Unix epoch
|
||||
format time stamp), <replaceable>num_of_transactions</> is the number of transactions
|
||||
within the interval, <replaceable>latency_sum</replaceable> is a sum of latencies
|
||||
(so you can compute average latency easily). The following two fields are useful
|
||||
for variance estimation - <replaceable>latency_sum</> is a sum of latencies and
|
||||
|
@ -13,7 +13,7 @@
|
||||
|
||||
<refnamediv>
|
||||
<refname>pg_test_fsync</refname>
|
||||
<refpurpose>determine fastest wal_sync_method for <productname>PostgreSQL</productname></refpurpose>
|
||||
<refpurpose>determine fastest <varname>wal_sync_method</varname> for <productname>PostgreSQL</productname></refpurpose>
|
||||
</refnamediv>
|
||||
|
||||
<refsynopsisdiv>
|
||||
|
@ -403,7 +403,7 @@ pg_upgrade.exe
|
||||
exit and you will have to revert to the old cluster as outlined in <xref linkend="pgupgrade-step-revert">
|
||||
below. To try <command>pg_upgrade</command> again, you will need to modify the old
|
||||
cluster so the pg_upgrade schema restore succeeds. If the problem is a
|
||||
contrib module, you might need to uninstall the contrib module from
|
||||
<filename>contrib</filename> module, you might need to uninstall the <filename>contrib</filename> module from
|
||||
the old cluster and install it in the new cluster after the upgrade,
|
||||
assuming the module is not being used to store user data.
|
||||
</para>
|
||||
|
@ -564,11 +564,11 @@ EOF
|
||||
<para>
|
||||
Show help about <application>psql</application> and exit. The optional
|
||||
<replaceable class="parameter">topic</> parameter (defaulting
|
||||
to <literal>options</literal>) selects which part of psql is
|
||||
to <literal>options</literal>) selects which part of <application>psql</application> is
|
||||
explained: <literal>commands</> describes <application>psql</>'s
|
||||
backslash commands; <literal>options</> describes the commandline
|
||||
switches that can be passed to <application>psql</>;
|
||||
and <literal>variables</> shows help about about psql configuration
|
||||
backslash commands; <literal>options</> describes the command-line
|
||||
options that can be passed to <application>psql</>;
|
||||
and <literal>variables</> shows help about about <application>psql</application> configuration
|
||||
variables.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -2367,7 +2367,7 @@ lo_import 152801
|
||||
<term><literal>unicode_border_style</literal></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Sets the border drawing style for the unicode linestyle to one
|
||||
Sets the border drawing style for the <literal>unicode</literal> line style to one
|
||||
of <literal>single</literal> or <literal>double</literal>.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -2377,7 +2377,7 @@ lo_import 152801
|
||||
<term><literal>unicode_column_style</literal></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Sets the column drawing style for the unicode linestyle to one
|
||||
Sets the column drawing style for the <literal>unicode</literal> line style to one
|
||||
of <literal>single</literal> or <literal>double</literal>.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -2387,7 +2387,7 @@ lo_import 152801
|
||||
<term><literal>unicode_header_style</literal></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Sets the header drawing style for the unicode linestyle to one
|
||||
Sets the header drawing style for the <literal>unicode</literal> line style to one
|
||||
of <literal>single</literal> or <literal>double</literal>.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -2690,11 +2690,11 @@ testdb=> <userinput>\setenv LESS -imx4F</userinput>
|
||||
<para>
|
||||
Shows help information. The optional
|
||||
<replaceable class="parameter">topic</> parameter
|
||||
(defaulting to <literal>commands</>) selects which part of psql is
|
||||
(defaulting to <literal>commands</>) selects which part of <application>psql</application> is
|
||||
explained: <literal>commands</> describes <application>psql</>'s
|
||||
backslash commands; <literal>options</> describes the commandline
|
||||
switches that can be passed to <application>psql</>;
|
||||
and <literal>variables</> shows help about about psql configuration
|
||||
backslash commands; <literal>options</> describes the command-line
|
||||
options that can be passed to <application>psql</>;
|
||||
and <literal>variables</> shows help about about <application>psql</application> configuration
|
||||
variables.
|
||||
</para>
|
||||
</listitem>
|
||||
|
@ -101,7 +101,7 @@
|
||||
</para>
|
||||
|
||||
<para>
|
||||
This change causes conversions of booleans to strings to
|
||||
This change causes conversions of Booleans to strings to
|
||||
produce <literal>true</> or <literal>false</>, not <literal>t</>
|
||||
or <literal>f</>. Other type conversions may succeed in more cases
|
||||
than before; for example, assigning a numeric value <literal>3.9</> to
|
||||
@ -426,7 +426,7 @@ FIXME: Add Andres
|
||||
2015-04-27 [dcbf594] Stephe..: Improve qual pushdown for RLS and SB views
|
||||
-->
|
||||
<para>
|
||||
Allow non-LEAKPROOF functions to be passed into security barrier
|
||||
Allow non-leakproof functions to be passed into security barrier
|
||||
views if the function does not reference any table columns
|
||||
(Dean Rasheed)
|
||||
</para>
|
||||
@ -646,13 +646,13 @@ FIXME: Add docs about restartpoint behaviour change
|
||||
-->
|
||||
<para>
|
||||
Allow recording of transaction
|
||||
commit timestamps when configuration parameter <xref
|
||||
commit time stamps when configuration parameter <xref
|
||||
linkend="guc-track-commit-timestamp">
|
||||
is enabled (Álvaro Herrera, Petr Jelínek)
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Timestamp information can be accessed using functions <link
|
||||
Time stamp information can be accessed using functions <link
|
||||
linkend="functions-commit-timestamp"><function>pg_xact_commit_timestamp()</></>
|
||||
and <function>pg_last_committed_xact()</>.
|
||||
</para>
|
||||
@ -1583,7 +1583,7 @@ FIXME: Add more specifics?
|
||||
2014-08-27 [8167a38] Jeff D..: Allow multibyte characters as escape in SIMILA..
|
||||
-->
|
||||
<para>
|
||||
Allow multi-byte characters as escape in <link
|
||||
Allow multibyte characters as escape in <link
|
||||
linkend="functions-similarto-regexp"><literal>SIMILAR TO</></>
|
||||
and <link linkend="functions-string-sql"><literal>SUBSTRING</></>
|
||||
(Jeff Davis)
|
||||
@ -1630,7 +1630,7 @@ FIXME: Add more specifics?
|
||||
Previously only <literal>:=</> could be used. This requires removing
|
||||
the possibility for <literal>=></> to be a user-defined operator.
|
||||
Creation of user-defined <literal>=></> operators has been issuing
|
||||
warnings since Postgres 9.0.
|
||||
warnings since PostgreSQL 9.0.
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
@ -1640,7 +1640,7 @@ FIXME: Add more specifics?
|
||||
-->
|
||||
<para>
|
||||
Add <acronym>POSIX</>-compliant rounding for platforms that use
|
||||
Postgres-supplied rounding functions (Pedro Gimeno Fortea)
|
||||
PostgreSQL-supplied rounding functions (Pedro Gimeno Fortea)
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
@ -1694,7 +1694,7 @@ FIXME: Add more specifics?
|
||||
<para>
|
||||
Add <link
|
||||
linkend="monitoring-stats-funcs-table"><function>pg_stat_get_snapshot_timestamp()</></>
|
||||
to output the timestamp of the statistics snapshot (Matt Kelly)
|
||||
to output the time stamp of the statistics snapshot (Matt Kelly)
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@ -2025,7 +2025,7 @@ FIXME: Add more specifics?
|
||||
<para>
|
||||
Add <application>psql</> <link
|
||||
linkend="APP-PSQL-variables"><envar>PROMPT</></> variables option
|
||||
(<literal>%l</>) to display the multi-line statement line number
|
||||
(<literal>%l</>) to display the multiline statement line number
|
||||
(Sawada Masahiko)
|
||||
</para>
|
||||
</listitem>
|
||||
@ -2519,7 +2519,7 @@ FIXME: Improve description, link
|
||||
2015-05-19 [0b28ea7] Tom Lane: Avoid collation dependence in indexes of syste..
|
||||
-->
|
||||
<para>
|
||||
Change index opclass for columns <link
|
||||
Change index operator class for columns <link
|
||||
linkend="catalog-pg-seclabel"><structname>pg_seclabel</></>.<structname>provider</>
|
||||
and <link
|
||||
linkend="catalog-pg-shseclabel"><structname>pg_shseclabel</></>.<structname>provider</>
|
||||
@ -2555,7 +2555,7 @@ FIXME: Improve description, link
|
||||
2014-12-08 [8001fe6] Simon ..: Windows: use GetSystemTimePreciseAsFileTime if ..
|
||||
-->
|
||||
<para>
|
||||
Allow higher-precision timestamp resolution on <systemitem
|
||||
Allow higher-precision time stamp resolution on <systemitem
|
||||
class="osname">Windows 8</> or <systemitem class="osname">Windows
|
||||
Server 2012</> and later Windows systems (Craig Ringer)
|
||||
</para>
|
||||
@ -2687,7 +2687,7 @@ FIXME: Improve description, link
|
||||
2014-06-30 [1b24887] Tom Lane: Allow multi-character source strings in contrib..
|
||||
-->
|
||||
<para>
|
||||
Allow multi-character source strings in <link
|
||||
Allow multicharacter source strings in <link
|
||||
linkend="unaccent"><application>unaccent</></> (Tom Lane)
|
||||
</para>
|
||||
|
||||
|
@ -49,7 +49,7 @@
|
||||
replay progress in a safe manner. When the applying process, or the whole
|
||||
cluster, dies, it needs to be possible to find out up to where data has
|
||||
successfully been replicated. Naive solutions to this like updating a row in
|
||||
a table for every replayed transaction have problems like runtime overhead
|
||||
a table for every replayed transaction have problems like run-time overhead
|
||||
bloat.
|
||||
</para>
|
||||
|
||||
@ -58,7 +58,7 @@
|
||||
marked as replaying from a remote node (using the
|
||||
<link linkend="pg-replication-origin-session-setup"><function>pg_replication_origin_session_setup()</function></link>
|
||||
function). Additionally the <acronym>LSN</acronym> and commit
|
||||
timestamp of every source transaction can be configured on a per
|
||||
time stamp of every source transaction can be configured on a per
|
||||
transaction basis using
|
||||
<link linkend="pg-replication-origin-xact-setup"><function>pg_replication_origin_xact_setup()</function></link>.
|
||||
If that's done replication progress will persist in a crash safe
|
||||
|
Loading…
x
Reference in New Issue
Block a user