<para>
In some situations it is worthwhile to rebuild indexes periodically
- with the <command>REINDEX</> command.
+ with the <xref linkend="sql-reindex" endterm="sql-reindex-title">
+ command.
</para>
<para>
<title>Compatibility</title>
<para>
- <command>ALTER DOMAIN</command> conforms with <acronym>SQL:2003</acronym>,
+ <command>ALTER DOMAIN</command> conforms to the <acronym>SQL</acronym>
+ standard,
except for the <literal>OWNER</> and <literal>SET SCHEMA</> variants,
which are <productname>PostgreSQL</productname> extensions.
</para>
<literal>CALLED ON NULL INPUT</literal> changes the function so
that it will be invoked when some or all of its arguments are
null. <literal>RETURNS NULL ON NULL INPUT</literal> or
- <literal>STRICT</literal> changes the function so that it
- always returns null if any of its arguments are null. See <xref
+ <literal>STRICT</literal> changes the function so that it is not
+ invoked if any of its arguments are null; instead, a null result
+ is assumed automatically. See <xref
linkend="sql-createfunction"> for more information.
</para>
</listitem>
<listitem>
<para>
Change the volatility of the function to the specified
- type. See <xref linkend="sql-createfunction"> for more
- information about function volatility.
+ setting. See <xref linkend="sql-createfunction"> for details.
</para>
</listitem>
</varlistentry>
properties of a function to be modified, but does not provide the
ability to rename a function, make a function a security definer,
or change the owner, schema, or volatility of a function. The standard also
- requires the <literal>RESTRICT</> key word; it is optional in
+ requires the <literal>RESTRICT</> key word, which is optional in
<productname>PostgreSQL</>.
</para>
</refsect1>
<title>Compatibility</title>
<para>
- <command>ALTER SEQUENCE</command> conforms with <acronym>SQL:2003</acronym>,
+ <command>ALTER SEQUENCE</command> conforms to the <acronym>SQL</acronym>
+ standard,
except for the <literal>SET SCHEMA</literal> variant, which is a
<productname>PostgreSQL</productname> extension.
</para>
<title>Compatibility</title>
<para>
- The <command>CREATE CAST</command> command conforms to SQL:2003,
- except that SQL:2003 does not make provisions for binary-compatible
+ The <command>CREATE CAST</command> command conforms to the
+ <acronym>SQL</acronym> standard,
+ except that SQL does not make provisions for binary-compatible
types or extra arguments to implementation functions.
<literal>AS IMPLICIT</> is a <productname>PostgreSQL</productname>
extension, too.
constraints individually.
</para>
- <note>
+ <caution>
<para>
- Keep in mind also that declaring a function result value as a domain
+ At present, declaring a function result value as a domain
is pretty dangerous, because none of the PLs enforce domain constraints
- on their results.
+ on their results. You'll need to make sure that the function code itself
+ respects the constraints. In <application>PL/pgSQL</>, one possible
+ workaround is to explicitly cast the result value to the domain type
+ when you return it. <application>PL/pgSQL</> does not enforce domain
+ constraints for local variables within functions, either.
</para>
- </note>
+ </caution>
</refsect1>
<refsect1>
change even within a single table scan, so no optimizations can be
made. Relatively few database functions are volatile in this sense;
some examples are <literal>random()</>, <literal>currval()</>,
- <literal>timeofday()</>. Note that any function that has side-effects
- must be classified volatile, even if its result is quite predictable,
- to prevent calls from being optimized away; an example is
+ <literal>timeofday()</>. But note that any function that has
+ side-effects must be classified volatile, even if its result is quite
+ predictable, to prevent calls from being optimized away; an example is
<literal>setval()</>.
</para>
</para>
<para>
- The key word <literal>EXTERNAL</literal> is present for SQL
- conformance but is optional since, unlike in SQL, this feature
- does not only apply to external functions.
+ The key word <literal>EXTERNAL</literal> is allowed for SQL
+ conformance, but it is optional since, unlike in SQL, this feature
+ applies to all functions not only external ones.
</para>
</listitem>
</varlistentry>
<title>Compatibility</title>
<para>
- A <command>CREATE FUNCTION</command> command is defined in SQL:2003.
+ A <command>CREATE FUNCTION</command> command is defined in SQL:1999 and later.
The <productname>PostgreSQL</productname> version is similar but
not fully compatible. The attributes are not portable, neither are the
different available languages.
<title>Compatibility</title>
<para>
- <command>CREATE SEQUENCE</command> is is specified in <acronym>SQL:2003</acronym>.
- <productname>PostgreSQL</productname> conforms with the standard, with the following exceptions:
+ <command>CREATE SEQUENCE</command> conforms to the <acronym>SQL</acronym>
+ standard, with the following exceptions:
<itemizedlist>
<listitem><para>The standard's <literal>AS <data type></literal> expression is not supported.</para></listitem>
<listitem><para>Obtaining the next value is done using the <function>nextval()</> function instead of the standard's <command>NEXT VALUE FOR</command> expression.</para></listitem>
<refsynopsisdiv>
<synopsis>
-CREATE [ [ GLOBAL | LOCAL ] { TEMPORARY | TEMP } ] TABLE <replaceable class="PARAMETER">table_name</replaceable> (
- [ <replaceable class="PARAMETER">column_name</replaceable> <replaceable class="PARAMETER">data_type</replaceable> [ DEFAULT <replaceable>default_expr</> ] [ <replaceable class="PARAMETER">column_constraint</replaceable> [ ... ] ]
+CREATE [ [ GLOBAL | LOCAL ] { TEMPORARY | TEMP } ] TABLE <replaceable class="PARAMETER">table_name</replaceable> ( [
+ { <replaceable class="PARAMETER">column_name</replaceable> <replaceable class="PARAMETER">data_type</replaceable> [ DEFAULT <replaceable>default_expr</> ] [ <replaceable class="PARAMETER">column_constraint</replaceable> [ ... ] ]
| <replaceable>table_constraint</replaceable>
- | LIKE <replaceable>parent_table</replaceable> [ { INCLUDING | EXCLUDING } DEFAULTS ] ] [, ... ]
-)
+ | LIKE <replaceable>parent_table</replaceable> [ { INCLUDING | EXCLUDING } DEFAULTS ] }
+ [, ... ]
+] )
[ INHERITS ( <replaceable>parent_table</replaceable> [, ... ] ) ]
[ WITH OIDS | WITHOUT OIDS ]
[ ON COMMIT { PRESERVE ROWS | DELETE ROWS | DROP } ]
<title id="SQL-CREATETABLE-compatibility-title">Compatibility</title>
<para>
- The <command>CREATE TABLE</command> command conforms to SQL-92 and
- to a subset of SQL:2003, with exceptions listed below.
+ The <command>CREATE TABLE</command> command conforms to the
+ <acronym>SQL</acronym> standard, with exceptions listed below.
</para>
<refsect2>
<para>
Multiple inheritance via the <literal>INHERITS</literal> clause is
a <productname>PostgreSQL</productname> language extension.
- SQL:2003 defines single inheritance using a
- different syntax and different semantics. SQL:2003-style
+ SQL:1999 and later define single inheritance using a
+ different syntax and different semantics. SQL:1999-style
inheritance is not yet supported by
<productname>PostgreSQL</productname>.
</para>
<refsynopsisdiv>
<synopsis>
-CREATE [ [ GLOBAL | LOCAL ] { TEMPORARY | TEMP } ] TABLE <replaceable>table_name</replaceable> [ (<replaceable>column_name</replaceable> [, ...] ) ] [ [ WITH | WITHOUT ] OIDS ]
+CREATE [ [ GLOBAL | LOCAL ] { TEMPORARY | TEMP } ] TABLE <replaceable>table_name</replaceable>
+ [ (<replaceable>column_name</replaceable> [, ...] ) ] [ [ WITH | WITHOUT ] OIDS ]
AS <replaceable>query</replaceable>
</synopsis>
</refsynopsisdiv>
<para>
Prior to <productname>PostgreSQL</productname> 8.0, <command>CREATE
TABLE AS</command> always included OIDs in the table it
-
produced. As of <productname>PostgreSQL</productname> 8.0,
+
created. As of <productname>PostgreSQL</productname> 8.0,
the <command>CREATE TABLE AS</command> command allows the user to
explicitly specify whether OIDs should be included. If the
presence of OIDs is not explicitly specified,
the <xref linkend="guc-default-with-oids"> configuration variable is
- used. While this variable currently defaults to true, the default
- value may be changed in the future. Therefore, applications that
+ used. As of <productname>PostgreSQL</productname> 8.1,
+ this variable is false by default, so the default behavior is not
+ identical to pre-8.0 releases. Applications that
require OIDs in the table created by <command>CREATE TABLE
- AS</command> should explicitly specify <literal>WITH
- OIDS</literal> to ensure compatibility with future versions
- of <productname>PostgreSQL</productname>.
+ AS</command> should explicitly specify <literal>WITH OIDS</literal>
+ to ensure proper behavior.
</para>
</refsect1>
<title>Compatibility</title>
<para>
- <command>CREATE TABLE AS</command> is specified by the SQL:2003
- standard. There are some small differences between the definition
- of the command in SQL:2003 and its implementation in
- <productname>PostgreSQL</>:
+ <command>CREATE TABLE AS</command> conforms to the <acronym>SQL</acronym>
+ standard, with the following exceptions:
<itemizedlist spacing="compact">
<listitem>
<listitem>
<para>
- The standard defines a <literal>WITH DATA</literal> clause;
+ The standard defines a <literal>WITH [ NO ] DATA</literal> clause;
this is not currently implemented by <productname>PostgreSQL</>.
+ The behavior provided by <productname>PostgreSQL</> is equivalent
+ to the standard's <literal>WITH DATA</literal> case.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>WITH/WITHOUT OIDS</> is a <productname>PostgreSQL</>
+ extension.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <productname>PostgreSQL</> handles temporary tables in a way
+ rather different from the standard; see
+ <xref linkend="sql-createtable" endterm="sql-createtable-title">
+ for details.
</para>
</listitem>
</itemizedlist>
<para>
The <command>CREATE TRIGGER</command> statement in
<productname>PostgreSQL</productname> implements a subset of the
- SQL:2003 standard. The following functionality is currently missing:
+ <acronym>SQL</> standard. The following functionality is currently missing:
<itemizedlist>
<listitem>
<para>
- SQL:2003 allows triggers to fire on updates to specific columns
+ SQL allows triggers to fire on updates to specific columns
(e.g., <literal>AFTER UPDATE OF col1, col2</literal>).
</para>
</listitem>
<listitem>
<para>
- SQL:2003 allows you to define aliases for the <quote>old</quote>
+ SQL allows you to define aliases for the <quote>old</quote>
and <quote>new</quote> rows or tables for use in the definition
of the triggered action (e.g., <literal>CREATE TRIGGER ... ON
tablename REFERENCING OLD ROW AS somename NEW ROW AS othername
<listitem>
<para>
<productname>PostgreSQL</productname> only allows the execution
- of a user-defined function for the triggered action. SQL:2003
+ of a user-defined function for the triggered action. The standard
allows the execution of a number of other SQL commands, such as
- <command>CREATE TABLE</command> as triggered action. This
+ <command>CREATE TABLE</command> as the triggered action. This
limitation is not hard to work around by creating a user-defined
function that executes the desired commands.
</para>
</para>
<para>
- SQL:2003 specifies that multiple triggers should be fired in
+ SQL specifies that multiple triggers should be fired in
time-of-creation order. <productname>PostgreSQL</productname> uses
name order, which was judged more convenient to work with.
</para>
<para>
This <command>CREATE TYPE</command> command is a
<productname>PostgreSQL</productname> extension. There is a
- <command>CREATE TYPE</command> statement in SQL:2003 that is rather
- different in detail.
+ <command>CREATE TYPE</command> statement in the <acronym>SQL</> standard
+ that is rather different in detail.
</para>
</refsect1>
<refsynopsisdiv>
<synopsis>
-CREATE [ OR REPLACE ] [ TEMP | TEMPORARY ] VIEW <replaceable class="PARAMETER">name</replaceable> [ ( <replaceable
-class="PARAMETER">column_name</replaceable> [, ...] ) ] AS <replaceable class="PARAMETER">query</replaceable>
+CREATE [ OR REPLACE ] [ TEMP | TEMPORARY ] VIEW <replaceable class="PARAMETER">name</replaceable> [ ( <replaceable class="PARAMETER">column_name</replaceable> [, ...] ) ]
+ AS <replaceable class="PARAMETER">query</replaceable>
</synopsis>
</refsynopsisdiv>
<para>
If specified, the view is created as a temporary view.
Temporary views are automatically dropped at the end of the
- current session. Temporary views are automatically placed in the
- current backend's local temporary schema, so it is illegal to
- specify a schema-qualified name for a temporary view. Existing
+ current session. Existing
permanent relations with the same name are not visible to the
current session while the temporary view exists, unless they are
referenced with schema-qualified names.
</para>
<para>
- If any of the base tables referenced by the view are temporary,
+ If any of the tables referenced by the view are temporary,
the view is created as a temporary view (whether
<literal>TEMPORARY</literal> is specified or not).
</para>
The SQL standard specifies some additional capabilities for the
<command>CREATE VIEW</command> statement:
<synopsis>
-CREATE VIEW <replaceable class="parameter">name</replaceable> [ ( <replaceable class="parameter">column</replaceable> [, ...] ) ]
- AS query
+CREATE VIEW <replaceable class="parameter">name</replaceable> [ ( <replaceable class="parameter">column_name</replaceable> [, ...] ) ]
+ AS <replaceable class="PARAMETER">query</replaceable>
[ WITH [ CASCADED | LOCAL ] CHECK OPTION ]
</synopsis>
</para>
<para>
<command>CREATE OR REPLACE VIEW</command> is a
<productname>PostgreSQL</productname> language extension.
+ So is the concept of a temporary view.
</para>
</refsect1>
<listitem>
<para>
The new user will not be a superuser.
+ This is the default.
</para>
</listitem>
</varlistentry>
<listitem>
<para>
The new user will not be allowed to create databases.
+ This is the default.
</para>
</listitem>
</varlistentry>
<listitem>
<para>
The new user will not be allowed to create new roles.
+ This is the default.
</para>
</listitem>
</varlistentry>
<para>
By default, <command>DELETE</command> will delete rows in the
- specified table and all its subtables. If you wish to delete only
+ specified table and all its child tables. If you wish to delete only
from the specific table mentioned, you must use the
<literal>ONLY</literal> clause.
</para>
<title>Parameters</title>
<variablelist>
+ <varlistentry>
+ <term><literal>ONLY</></term>
+ <listitem>
+ <para>
+ If specified, delete rows from the named table only. When not
+ specified, any tables inheriting from the named table are also processed.
+ </para>
+ </listitem>
+ </varlistentry>
+
<varlistentry>
<term><replaceable class="parameter">table</replaceable></term>
<listitem>
to the list of tables that can be specified in the <xref
linkend="sql-from" endterm="sql-from-title"> of a
<command>SELECT</command> statement; for example, an alias for
- the table name can be specified.
+ the table name can be specified. Do not repeat the target table
+ in the <replaceable class="PARAMETER">usinglist</replaceable>,
+ unless you wish to set up a self-join.
</para>
</listitem>
</varlistentry>
<term><replaceable class="parameter">condition</replaceable></term>
<listitem>
<para>
- A value expression that returns a value of type
- <type>boolean</type> that determines the rows which are to be
+ An expression returning a value of type
+ <type>boolean</type>, which determines the rows that are to be
deleted.
</para>
</listitem>
<title>Compatibility</title>
<para>
- <command>DROP SEQUENCE</command> conforms with
- <acronym>SQL:2003</acronym>, except that the standard only allows one
+ <command>DROP SEQUENCE</command> conforms to the <acronym>SQL</acronym>
+ standard, except that the standard only allows one
sequence to be dropped per command.
</para>
</refsect1>
</para>
<para>
- The options <option>--cc</option>, <option>--cppflags</option>,
+ The options <option>--docdir</option>, <option>--pkgincludedir</option>,
+ <option>--localedir</option>, <option>--mandir</option>,
+ <option>--sharedir</option>, <option>--sysconfdir</option>,
+ <option>--cc</option>, <option>--cppflags</option>,
<option>--cflags</option>, <option>--cflags_sl</option>,
<option>--ldflags</option>, <option>--ldflags_sl</option>,
and <option>--libs</option> are new in <productname>PostgreSQL</> 8.1.
</listitem>
</varlistentry>
- <varlistentry>
- <term><option>-E <replaceable class="parameter">encoding</replaceable></option></term>
- <term><option>--encoding=<replaceable class="parameter">encoding</replaceable></option></term>
- <listitem>
- <para>
- Create the dump in the specified encoding. By default, the dump is
- created in the database encoding.
- </para>
- </listitem>
+ <varlistentry>
+ <term><option>-E <replaceable class="parameter">encoding</replaceable></option></term>
+ <term><option>--encoding=<replaceable class="parameter">encoding</replaceable></option></term>
+ <listitem>
+ <para>
+ Create the dump in the specified character set encoding. By default,
+ the dump is created in the database encoding. (Another way to get the
+ same result is to set the <envar>PGCLIENTENCODING</envar> environment
+ variable to the desired dump encoding.)
+ </para>
+ </listitem>
</varlistentry>
-
<varlistentry>
<term><option>-f <replaceable class="parameter">file</replaceable></option></term>
<term><option>--file=<replaceable class="parameter">file</replaceable></option></term>
<term><option>--use-set-session-authorization</></term>
<listitem>
<para>
- Output SQL standard SET SESSION AUTHORIZATION commands instead of
- ALTER OWNER commands. This makes the dump more standards compatible,
- but depending on the history of the objects in the dump, may not
- restore properly.
+ Output SQL-standard <command>SET SESSION AUTHORIZATION</> commands
+ instead of <command>ALTER OWNER</> commands to determine object
+ ownership. This makes the dump more standards compatible, but
+ depending on the history of the objects in the dump, may not restore
+ properly. Also, a dump using <command>SET SESSION AUTHORIZATION</>
+ will certainly require superuser privileges to restore correctly,
+ whereas <command>ALTER OWNER</> requires lesser privileges.
</para>
</listitem>
</varlistentry>
<term><option>--use-set-session-authorization</></term>
<listitem>
<para>
- Output SQL standard SET SESSION AUTHORIZATION commands instead of
- ALTER OWNER commands. This makes the dump more standards compatible,
- but depending on the history of the objects in the dump, may not
- restore properly.
+ Output SQL-standard <command>SET SESSION AUTHORIZATION</> commands
+ instead of <command>ALTER OWNER</> commands to determine object
+ ownership. This makes the dump more standards compatible, but
+ depending on the history of the objects in the dump, may not restore
+ properly.
</para>
</listitem>
</varlistentry>
<term><option>--schema=<replaceable class="parameter">schema</replaceable></option></term>
<listitem>
<para>
- Restore only definitions and/or data in the named schema. Not to be
- confused with the <option>-s</option> option. This can be combined with
- <option>-t</option> option.
+ Restore only objects that are in the named schema. This can be
+ combined with the <option>-t</option> option to restore just a
+ specific table.
</para>
</listitem>
</varlistentry>
<term><option>--schema-only</option></term>
<listitem>
<para>
- Restore only the schema (data definitions), not the data.
- Sequence values will be reset.
+ Restore only the schema (data definitions), not the data (table
+ contents). Sequence current values will not be restored, either.
+ (Do not confuse this with the <option>--schema</> option, which
+ uses the word <quote>schema</> in a different meaning.)
</para>
</listitem>
</varlistentry>
<term><option>--use-set-session-authorization</option></term>
<listitem>
<para>
- Output SQL standard <command>SET SESSION AUTHORIZATION</>
- commands instead of <command>ALTER OWNER</> commands. This
- makes the dump more standards compatible, but depending on the
- history of the objects in the dump, may not restore properly.
+ Output SQL-standard <command>SET SESSION AUTHORIZATION</> commands
+ instead of <command>ALTER OWNER</> commands to determine object
+ ownership. This makes the dump more standards compatible, but
+ depending on the history of the objects in the dump, may not restore
+ properly.
</para>
</listitem>
</varlistentry>
<term><option>--log-file <replaceable class="parameter">filename</replaceable></></term>
<listitem>
<para>
- Write all query output into file <replaceable
- class="parameter">filename</replaceable> in addition to the regular output source.
+ Write all query output into file <replaceable
+ class="parameter">filename</replaceable>, in addition to the
+ normal output destination.
</para>
</listitem>
</varlistentry>
precede it by a backslash. Anything contained in single quotes is
furthermore subject to C-like substitutions for
<literal>\n</literal> (new line), <literal>\t</literal> (tab),
- <literal>\</literal><replaceable>digits</replaceable> (octal),
+ <literal>\</literal><replaceable>digits</replaceable> (octal), and
<literal>\x</literal><replaceable>digits</replaceable> (hexadecimal).
</para>
<listitem>
<para>
The filename that will be used to store the history list. The default
- value is <filename>~/.psql_history</filename>. For example, using:
+ value is <filename>~/.psql_history</filename>. For example, putting
<programlisting>
\set HISTFILE ~/.psql_history- :DBNAME
</programlisting>
- in <filename>~/.psqlrc</filename> will get <application>psql</application> to
- maintain a separate history for each database.
+ in <filename>~/.psqlrc</filename> will cause
+ <application>psql</application> to maintain a separate history for
+ each database.
</para>
<note>
<para>
<title>Compatibility</title>
<para>
- This command conforms to the SQL:2003 standard. The standard
+ This command conforms to the <acronym>SQL</> standard. The standard
specifies that the key word <literal>SAVEPOINT</literal> is
mandatory, but <productname>PostgreSQL</productname> allows it to
be omitted.
<title>Compatibility</title>
<para>
- The SQL:2003 standard specifies that the key word
+ The <acronym>SQL</> standard specifies that the key word
<literal>SAVEPOINT</> is mandatory, but <productname>PostgreSQL</>
- and <productname>Oracle</> allow it to be omitted. SQL:2003 allows
+ and <productname>Oracle</> allow it to be omitted. SQL allows
only <literal>WORK</>, not <literal>TRANSACTION</>, as a noise word
- after <literal>ROLLBACK</>. Also, SQL:2003 has an optional clause
+ after <literal>ROLLBACK</>. Also, SQL has an optional clause
<literal>AND [ NO ] CHAIN</> which is not currently supported by
<productname>PostgreSQL</>. Otherwise, this command conforms to
the SQL standard.
<title>Namespace Available to <literal>GROUP BY</literal> and <literal>ORDER BY</literal></title>
<para>
- In the SQL:2003 standard, an <literal>ORDER BY</literal> clause may
+ In the SQL-92 standard, an <literal>ORDER BY</literal> clause may
only use result column names or numbers, while a <literal>GROUP
BY</literal> clause may only use expressions based on input column
names. <productname>PostgreSQL</productname> extends each of
</para>
<para>
- SQL:2003 uses a slightly different definition which is not entirely upward
- compatible with SQL-92.
+ SQL:1999 and later use a slightly different definition which is not
+ entirely upward compatible with SQL-92.
In most cases, however, <productname>PostgreSQL</productname>
will interpret an <literal>ORDER BY</literal> or <literal>GROUP
- BY</literal> expression the same way SQL:2003 does.
+ BY</literal> expression the same way SQL:1999 does.
</para>
</refsect2>
</para>
<para>
- During <command>VACUUM</command> execution, there can be a substantial
- increase in I/O traffic, which cause poor performance for other active
- sessions. Therefore, it is sometimes advisable to use
- the cost-based vacuum delay feature. See <xref
- linkend="runtime" endterm="runtime-config-resource-vacuum-cost-title"> for more
- details.
+ <command>VACUUM</command> causes a substantial increase in I/O traffic,
+ which can cause poor performance for other active sessions. Therefore,
+ it is sometimes advisable to use the cost-based vacuum delay feature.
+ See <xref linkend="runtime-config-resource-vacuum-cost"> for details.
</para>
</refsect1>
<simplelist type="inline">
<member><xref linkend="app-vacuumdb" endterm="app-vacuumdb-title"></member>
- <member><xref linkend="runtime" endterm="runtime-config-resource-vacuum-cost-title"></member>
+ <member><xref linkend="runtime-config-resource-vacuum-cost" endterm="runtime-config-resource-vacuum-cost-title"></member>
</simplelist>
</refsect1>
</refentry>
<application>pg_restore</> (Richard van den Berg)
</para>
<para>
- This allows only objects from a specified schema to be restored.
+ This allows just the objects in a specified schema to be restored.
</para>
</listitem>
<listitem>
<para>
- Allow <application>pg_dump</> to dump a consistent snapshot of
- large objects (Tom)
+ Allow <application>pg_dump</> to dump large objects even in
+ text mode (Tom)
+ </para>
+ <para>
+ With this change, large objects are now always dumped; the former
+ <option>-b</> switch is a no-op.
</para>
</listitem>
<listitem>
<para>
- Allow <application>pg_dump</> to dump large objects even in
- text mode (Tom)
+ Allow <application>pg_dump</> to dump a consistent snapshot of
+ large objects (Tom)
</para>
</listitem>
projects / users / bernd / postgres.git / commitdiff