git.postgresql.org Git - postgresql.git/commitdiff

diff --git a/doc/src/sgml/backup.sgml b/doc/src/sgml/backup.sgml

index 75dabe9f29f804a78d7513f5c0a05eb8f2e1990e..7413666382c1d228e63f99097299c6df96e727a1 100644 (file)

--- a/doc/src/sgml/backup.sgml

+++ b/doc/src/sgml/backup.sgml

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>

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>

diff --git a/doc/src/sgml/brin.sgml b/doc/src/sgml/brin.sgml

index 574803800962be9f442de828b84a0c81e4e8e1d6..dc5405e114976c85cec0f70886f3fe57cd57c90a 100644 (file)

--- a/doc/src/sgml/brin.sgml

+++ b/doc/src/sgml/brin.sgml

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 datatypes 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.

</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 datatype 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.

diff --git a/doc/src/sgml/catalogs.sgml b/doc/src/sgml/catalogs.sgml

index b4ea227c637f2a999c8cd8ee33319a332d7a4070..14479b950c55ab61d76c77d9c1bd5e514cf9043b 100644 (file)

--- a/doc/src/sgml/catalogs.sgml

+++ b/doc/src/sgml/catalogs.sgml

<row>

<entry><structfield>sourcefile</structfield></entry>

<entry><structfield>text</structfield></entry>

- <entry>Full pathname of the configuration file</entry>

+ <entry>Full pathname of the configuration file</entry>

</row>

<row>

<entry><structfield>sourceline</structfield></entry>

diff --git a/doc/src/sgml/client-auth.sgml b/doc/src/sgml/client-auth.sgml

index ba04bdf71ae4a5832f97c9a855e8bd3c05ecd581..5eef08fb00c068b40772e5292f00fe1fbad3176a 100644 (file)

--- a/doc/src/sgml/client-auth.sgml

+++ b/doc/src/sgml/client-auth.sgml

<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 username 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>

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>

<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 username when mapping.

</para>

</listitem>

</varlistentry>

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>

<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 username when mapping.

</para>

</listitem>

</varlistentry>

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.

diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml

index 9e7bcf5c4bc1bfd8fe5031db7eaef96490e2b15b..963838c2bafc30beff32a082de2c79956d44afe4 100644 (file)

--- a/doc/src/sgml/config.sgml

+++ b/doc/src/sgml/config.sgml

<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>

<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 changesets 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

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>

diff --git a/doc/src/sgml/custom-scan.sgml b/doc/src/sgml/custom-scan.sgml

index dc327b11b21b860a89b9ce1d8fa913c8e6b521de..a229326836a7b46bdb141192484c1da13d9e53cf 100644 (file)

--- a/doc/src/sgml/custom-scan.sgml

+++ b/doc/src/sgml/custom-scan.sgml

<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 bitmask, 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.

<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 bitmask with the same meaning as in

<structname>CustomPath</>.

<structfield>custom_plans</> can be used to store child

<structname>Plan</> nodes.

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 (rangetable 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

</para>

<para>

- <structfield>ss</> is initialized as for any other scanstate,

+ <structfield>ss</> is initialized as for any other scanstate,

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 bitmask 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

diff --git a/doc/src/sgml/ddl.sgml b/doc/src/sgml/ddl.sgml

index af1bda65af51042491de0576017b31cab8800acb..d78767ddd23fbbe449098e9d41f923b203c00ea7 100644 (file)

--- a/doc/src/sgml/ddl.sgml

+++ b/doc/src/sgml/ddl.sgml

</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>.

</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>

<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

<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>

diff --git a/doc/src/sgml/fdwhandler.sgml b/doc/src/sgml/fdwhandler.sgml

index 236157743a537c9b677c80e60bd1c499e6ead337..1dac7ad11eda5523a3ed767ace02215244569b9b 100644 (file)

--- a/doc/src/sgml/fdwhandler.sgml

+++ b/doc/src/sgml/fdwhandler.sgml

<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 rowtype 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

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 runtime in the tuples it returns.

</para>

<para>

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.

+ datatypes for row IDs in future.

</para>

<para>

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

+ targetlist (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

diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml

index b3b78d2daf635b2b0de816b4865441066195be96..22d4f615259471559c52d13b02cb3e856fc355fb 100644 (file)

--- a/doc/src/sgml/func.sgml

+++ b/doc/src/sgml/func.sgml

<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>

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>

<type>integer</type>

</entry>

<entry>

- Integer bitmask indicating which arguments are not being included in the current

+ Integer bitmask indicating which arguments are not being included in the current

grouping set

</entry>

</row>

</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>

<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>

diff --git a/doc/src/sgml/indices.sgml b/doc/src/sgml/indices.sgml

index 2d131c9109779223af849ed6d3bbc44aad66d614..23bbec6eb7112199ad5607b131274220332b9fac 100644 (file)

--- a/doc/src/sgml/indices.sgml

+++ b/doc/src/sgml/indices.sgml

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 datatypes 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:

diff --git a/doc/src/sgml/libpq.sgml b/doc/src/sgml/libpq.sgml

index 51cec0fc7c761650e10277d74466265e72d0a89c..0ee018edd2a722ee1d6fae783afc8b3f972bfec8 100644 (file)

--- a/doc/src/sgml/libpq.sgml

+++ b/doc/src/sgml/libpq.sgml

</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.

</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

diff --git a/doc/src/sgml/logicaldecoding.sgml b/doc/src/sgml/logicaldecoding.sgml

index 4f57765e918adddd30ecc2fdb9120d8d4ac109b4..02794cc5f274981256f630b6a143610a76d1daf9 100644 (file)

--- a/doc/src/sgml/logicaldecoding.sgml

+++ b/doc/src/sgml/logicaldecoding.sgml

<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>

for transactions and changes that have been filtered away.

</para>

<para>

- This is useful when implementing cascading or multidirectional

+ 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

diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml

index e34426ff18f5be7fe4076a25c30b00479b636034..b5d405024d8a4d4395beab427f9501dc617081ee 100644 (file)

--- a/doc/src/sgml/maintenance.sgml

+++ b/doc/src/sgml/maintenance.sgml

<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>

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>

diff --git a/doc/src/sgml/manage-ag.sgml b/doc/src/sgml/manage-ag.sgml

index 78ec509a8b5875343a5596cf084c02130838f369..260cf3610458dd686684c30a85e5c3ccd9e2bcd6 100644 (file)

--- a/doc/src/sgml/manage-ag.sgml

+++ b/doc/src/sgml/manage-ag.sgml

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>

diff --git a/doc/src/sgml/plpgsql.sgml b/doc/src/sgml/plpgsql.sgml

index 9a7763d18c908d5e82dad3b58a13bf51dd3f429a..a27bbc53a230cb65b168f234610688a0bb8bc353 100644 (file)

--- a/doc/src/sgml/plpgsql.sgml

+++ b/doc/src/sgml/plpgsql.sgml

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.)

<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>

diff --git a/doc/src/sgml/protocol.sgml b/doc/src/sgml/protocol.sgml

index 2caa84a12532cfca0eeae5eb425b51433c225e0c..34da8592c08934a5d2ae5ce43c754baff0ae869f 100644 (file)

--- a/doc/src/sgml/protocol.sgml

+++ b/doc/src/sgml/protocol.sgml

<listitem>

<para>

The frontend must now send a PasswordMessage containing the

- password (with username) encrypted via MD5, then encrypted

+ password (with username) 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,

diff --git a/doc/src/sgml/queries.sgml b/doc/src/sgml/queries.sgml

index 33db92fe290bb9537ab0e09d8b31c8e7a168fb83..ebacba856157505de1b2a1833c37902b3c0cce58 100644 (file)

--- a/doc/src/sgml/queries.sgml

+++ b/doc/src/sgml/queries.sgml

<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>

<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>

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

diff --git a/doc/src/sgml/recovery-config.sgml b/doc/src/sgml/recovery-config.sgml

index 61cf86ca80e6ec340bce00f24d6828a538bc2a77..22d1332b8b4338174471a25658b43a1b92c68dfa 100644 (file)

--- a/doc/src/sgml/recovery-config.sgml

+++ b/doc/src/sgml/recovery-config.sgml

<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 timestamp 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

diff --git a/doc/src/sgml/ref/alter_database.sgml b/doc/src/sgml/ref/alter_database.sgml

index 8b6fa5816f45b2589e039a5d9ed215b1426daf87..787cfff16736e04cd01d0dd912baf30ae65c5238 100644 (file)

--- a/doc/src/sgml/ref/alter_database.sgml

+++ b/doc/src/sgml/ref/alter_database.sgml

<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>

</listitem>

</varlistentry>

-

+

<varlistentry>

<term><replaceable class="parameter">allowconn</replaceable></term>

<listitem>

</para>

</listitem>

</varlistentry>

-

+

<varlistentry>

<term><replaceable class="parameter">connlimit</replaceable></term>

<listitem>

diff --git a/doc/src/sgml/ref/alter_table.sgml b/doc/src/sgml/ref/alter_table.sgml

index 92e9ce864f5aa8447d5c1593c82eb072757937f5..8e35cd937bd5c1aa0ded0ce9a2622b636c711450 100644 (file)

--- a/doc/src/sgml/ref/alter_table.sgml

+++ b/doc/src/sgml/ref/alter_table.sgml

</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

diff --git a/doc/src/sgml/ref/comment.sgml b/doc/src/sgml/ref/comment.sgml

index 656f5aae5babac6a38f28abcca6cf60d0a12fb24..10307385423762896e13a7fbed480ed7153e6f6c 100644 (file)

--- a/doc/src/sgml/ref/comment.sgml

+++ b/doc/src/sgml/ref/comment.sgml

<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>

diff --git a/doc/src/sgml/ref/create_database.sgml b/doc/src/sgml/ref/create_database.sgml

index 9711b1f98e3ebb524b918843099e2e698a112f54..0d187e29f523690ccc6c5a9ce9a48e1153657a65 100644 (file)

--- a/doc/src/sgml/ref/create_database.sgml

+++ b/doc/src/sgml/ref/create_database.sgml

<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>

</listitem>

</varlistentry>

-

+

<varlistentry>

<term><replaceable class="parameter">allowconn</replaceable></term>

<listitem>

</para>

</listitem>

</varlistentry>

-

+

<varlistentry>

<term><replaceable class="parameter">connlimit</replaceable></term>

<listitem>

diff --git a/doc/src/sgml/ref/create_domain.sgml b/doc/src/sgml/ref/create_domain.sgml

index 8b7848b820d058d21e09e1b860b7bd96255ce75c..3423bf9a32857abac5f367d8ae1145c4ded4ff90 100644 (file)

--- a/doc/src/sgml/ref/create_domain.sgml

+++ b/doc/src/sgml/ref/create_domain.sgml

<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>

diff --git a/doc/src/sgml/ref/create_function.sgml b/doc/src/sgml/ref/create_function.sgml

index cc2098c4420689ee5989de516810d24689dd21e4..bd11d2bc2895f876a357474f4b67848892732a5f 100644 (file)

--- a/doc/src/sgml/ref/create_function.sgml

+++ b/doc/src/sgml/ref/create_function.sgml

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">.

diff --git a/doc/src/sgml/ref/insert.sgml b/doc/src/sgml/ref/insert.sgml

index 233a48f4804407b47a97c46b553af33cefbb972a..8caf5fe855ff27d8ffc938415dadc1a243bb6335 100644 (file)

--- a/doc/src/sgml/ref/insert.sgml

+++ b/doc/src/sgml/ref/insert.sgml

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>

<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"

diff --git a/doc/src/sgml/ref/pg_basebackup.sgml b/doc/src/sgml/ref/pg_basebackup.sgml

index 5f8b9b7a3fd570aa375e024cad0161870412859b..4d679d0a0593541f9241e3c5337f036f0dc324b2 100644 (file)

--- a/doc/src/sgml/ref/pg_basebackup.sgml

+++ b/doc/src/sgml/ref/pg_basebackup.sgml

<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

<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>

diff --git a/doc/src/sgml/ref/pg_dump.sgml b/doc/src/sgml/ref/pg_dump.sgml

index 7467e868e35929f0f4d5560e3632f1b07d749e45..352d7e8a2b49d31c42f01909d30bac4829e2e78e 100644 (file)

--- a/doc/src/sgml/ref/pg_dump.sgml

+++ b/doc/src/sgml/ref/pg_dump.sgml

<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).

diff --git a/doc/src/sgml/ref/pg_recvlogical.sgml b/doc/src/sgml/ref/pg_recvlogical.sgml

index 4eda9ebdd1f42c5d5b77597cd840c660ca505e6f..9d0b58bc96b9329f070a8f712257a36276279a78 100644 (file)

--- a/doc/src/sgml/ref/pg_recvlogical.sgml

+++ b/doc/src/sgml/ref/pg_recvlogical.sgml

<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>

<para>

The following command-line options control the database connection parameters.

-

+

<variablelist>

<varlistentry>

<term><option>-d <replaceable>database</replaceable></option></term>

<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>

<term><option>--username=<replaceable>user</replaceable></option></term>

<listitem>

<para>

- Username to connect as. Defaults to current operating system user

+ Username to connect as. Defaults to current operating system user

name.

</para>

</listitem>

diff --git a/doc/src/sgml/ref/pg_rewind.sgml b/doc/src/sgml/ref/pg_rewind.sgml

index 32dc83f6e26dd9e47bb2f2f7310ea993f9fb479f..43c05d570cec8802cbac9915bfc1b24c4f3010f0 100644 (file)

--- a/doc/src/sgml/ref/pg_rewind.sgml

+++ b/doc/src/sgml/ref/pg_rewind.sgml

</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>

diff --git a/doc/src/sgml/ref/pg_xlogdump.sgml b/doc/src/sgml/ref/pg_xlogdump.sgml

index 1d78cf1a758a155246ed1627e8b6345347792b38..54ef0a725dd902f7adb5ca647e71765b357004c8 100644 (file)

--- a/doc/src/sgml/ref/pg_xlogdump.sgml

+++ b/doc/src/sgml/ref/pg_xlogdump.sgml

<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>

<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 filename.

</para>

</refsect1>

diff --git a/doc/src/sgml/ref/pgbench.sgml b/doc/src/sgml/ref/pgbench.sgml

index 2517a3abe7fae41f0d8ae5ee0698d5fad82bec58..ba3edc46307014f02b0e5cfc33efa6243d1a47af 100644 (file)

--- a/doc/src/sgml/ref/pgbench.sgml

+++ b/doc/src/sgml/ref/pgbench.sgml

</para>

<para>

- Typical output from pgbench looks like:

+ Typical output from <application>pgbench</application> looks like:

<screen>

transaction type: TPC-B (sort of)

<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>

<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:

<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.

<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

+ timestamp 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

<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 timestamp), <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

diff --git a/doc/src/sgml/ref/pgtestfsync.sgml b/doc/src/sgml/ref/pgtestfsync.sgml

index 5dcabe4b77d8c2e939e3d8f980b0c77aae3d2746..6e134c75df2c71c59132d999a4f63841536007ef 100644 (file)

--- a/doc/src/sgml/ref/pgtestfsync.sgml

+++ b/doc/src/sgml/ref/pgtestfsync.sgml

<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>

diff --git a/doc/src/sgml/ref/pgupgrade.sgml b/doc/src/sgml/ref/pgupgrade.sgml

index fcb03161edff261b212cb81510767e55c273f3ce..babeb0269bf45df80f4adc629009138896866230 100644 (file)

--- a/doc/src/sgml/ref/pgupgrade.sgml

+++ b/doc/src/sgml/ref/pgupgrade.sgml

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>

diff --git a/doc/src/sgml/ref/psql-ref.sgml b/doc/src/sgml/ref/psql-ref.sgml

index 6d47935e0dff01e6e6edae768de33f20f3c8d353..f5c9552ed10321e9828890493bca424a71770cea 100644 (file)

--- a/doc/src/sgml/ref/psql-ref.sgml

+++ b/doc/src/sgml/ref/psql-ref.sgml

<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>

<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>

<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>

<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>

<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>

diff --git a/doc/src/sgml/release-9.5.sgml b/doc/src/sgml/release-9.5.sgml

index 59f10f08ce1b31a59bd9d0f2578690bbc779c1b1..2672b556a2c341e28fb79ead1585c800d77f518f 100644 (file)

--- a/doc/src/sgml/release-9.5.sgml

+++ b/doc/src/sgml/release-9.5.sgml

</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

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>

-->

<para>

Allow recording of transaction

- commit timestamps when configuration parameter <xref

+ commit timestamps when configuration parameter <xref

linkend="guc-track-commit-timestamp">

is enabled (&Aacute;lvaro Herrera, Petr Jel&iacute;nek)

</para>

<para>

- Timestamp information can be accessed using functions <link

+ Timestamp information can be accessed using functions <link

linkend="functions-commit-timestamp"><function>pg_xact_commit_timestamp()</></>

and <function>pg_last_committed_xact()</>.

</para>

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)

Previously only <literal>:=</> could be used. This requires removing

the possibility for <literal>=&gt;</> to be a user-defined operator.

Creation of user-defined <literal>=&gt;</> operators has been issuing

- warnings since Postgres 9.0.

+ warnings since PostgreSQL 9.0.

</para>

</listitem>

-->

<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>

<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 timestamp of the statistics snapshot (Matt Kelly)

</para>

<para>

<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>

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</>

2014年12月08日 [8001fe6] Simon ..: Windows: use GetSystemTimePreciseAsFileTime if ..

-->

<para>

- Allow higher-precision timestamp resolution on <systemitem

+ Allow higher-precision timestamp resolution on <systemitem

class="osname">Windows 8</> or <systemitem class="osname">Windows

Server 2012</> and later Windows systems (Craig Ringer)

</para>

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>

diff --git a/doc/src/sgml/replication-origins.sgml b/doc/src/sgml/replication-origins.sgml

index 67f512207e333cb1191b7c67e88ce7abdec26f18..a7e8d40cf23627376c169e1cbfbbb1eed54a499c 100644 (file)

--- a/doc/src/sgml/replication-origins.sgml

+++ b/doc/src/sgml/replication-origins.sgml

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>

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

+ timestamp 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