Random copy-editing.
This commit is contained in:
parent
c119c554ed
commit
1d27de4cf4
@ -1,4 +1,4 @@
|
||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/array.sgml,v 1.32 2003/11/01 01:56:28 petere Exp $ -->
|
||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/array.sgml,v 1.33 2003/11/04 09:55:38 petere Exp $ -->
|
||||
|
||||
<sect1 id="arrays">
|
||||
<title>Arrays</title>
|
||||
@ -76,13 +76,45 @@ CREATE TABLE tictactoe (
|
||||
<sect2>
|
||||
<title>Array Value Input</title>
|
||||
|
||||
<para>
|
||||
Now we can show some <command>INSERT</command> statements. To write an array
|
||||
value as a literal constant, we enclose the element values within curly
|
||||
braces and separate them by commas. (If you know C, this is not unlike the
|
||||
C syntax for initializing structures.) We may put double quotes around any
|
||||
element value, and must do so if it contains commas or curly braces.
|
||||
(More details appear below.)
|
||||
<indexterm>
|
||||
<primary>array</primary>
|
||||
<secondary>constant</secondary>
|
||||
</indexterm>
|
||||
|
||||
<para>
|
||||
To write an array value as a literal constant, enclose the element
|
||||
values within curly braces and separate them by commas. (If you
|
||||
know C, this is not unlike the C syntax for initializing
|
||||
structures.) You may put double quotes around any element value,
|
||||
and must do so if it contains commas or curly braces. (More
|
||||
details appear below.) Thus, the general format of an array
|
||||
constant is the following:
|
||||
<synopsis>
|
||||
'{ <replaceable>val1</replaceable> <replaceable>delim</replaceable> <replaceable>val2</replaceable> <replaceable>delim</replaceable> ... }'
|
||||
</synopsis>
|
||||
where <replaceable>delim</replaceable> is the delimiter character
|
||||
for the type, as recorded in its <literal>pg_type</literal> entry.
|
||||
(For all built-in types, this is the comma character
|
||||
<quote><literal>,</literal></>.) Each
|
||||
<replaceable>val</replaceable> is either a constant of the array
|
||||
element type, or a subarray. An example of an array constant is
|
||||
<programlisting>
|
||||
'{{1,2,3},{4,5,6},{7,8,9}}'
|
||||
</programlisting>
|
||||
This constant is a two-dimensional, 3-by-3 array consisting of
|
||||
three subarrays of integers.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
(These kinds of array constants are actually only a special case of
|
||||
the generic type constants discussed in <xref
|
||||
linkend="sql-syntax-constants-generic">. The constant is initially
|
||||
treated as a string and passed to the array input conversion
|
||||
routine. An explicit type specification might be necessary.)
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Now we can show some <command>INSERT</command> statements.
|
||||
|
||||
<programlisting>
|
||||
INSERT INTO sal_emp
|
||||
@ -95,14 +127,15 @@ INSERT INTO sal_emp
|
||||
'{20000, 25000, 25000, 25000}',
|
||||
'{{"talk", "consult"}, {"meeting"}}');
|
||||
</programlisting>
|
||||
</para>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
A limitation of the present array implementation is that individual
|
||||
elements of an array cannot be SQL null values. The entire array
|
||||
can be set to null, but you can't have an array with some elements
|
||||
null and some not.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
A limitation of the present array implementation is that individual
|
||||
elements of an array cannot be SQL null values. The entire array can be set
|
||||
to null, but you can't have an array with some elements null and some
|
||||
not.
|
||||
</para>
|
||||
<para>
|
||||
This can lead to surprising results. For example, the result of the
|
||||
previous two inserts looks like this:
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/backup.sgml,v 2.30 2003/08/31 17:32:18 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/backup.sgml,v 2.31 2003/11/04 09:55:38 petere Exp $
|
||||
-->
|
||||
<chapter id="backup">
|
||||
<title>Backup and Restore</title>
|
||||
@ -155,8 +155,9 @@ pg_dump -h <replaceable>host1</> <replaceable>dbname</> | psql -h <replaceable>h
|
||||
|
||||
<tip>
|
||||
<para>
|
||||
Restore performance can be improved by increasing <literal>SORT_MEM</>
|
||||
(see <xref linkend="runtime-config-resource-memory">).
|
||||
Restore performance can be improved by increasing the
|
||||
configuration parameter <varname>sort_mem</varname> (see <xref
|
||||
linkend="runtime-config-resource-memory">).
|
||||
</para>
|
||||
</tip>
|
||||
</sect2>
|
||||
@ -333,12 +334,9 @@ tar -cf backup.tar /usr/local/pgsql/data
|
||||
going on. For this reason it is also not advisable to trust file
|
||||
systems that claim to support <quote>consistent
|
||||
snapshots</quote>. Information about stopping the server can be
|
||||
found in <xref linkend="postmaster-shutdown">.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Needless to say that you also need to shut down the server
|
||||
before restoring the data.
|
||||
found in <xref linkend="postmaster-shutdown">. Needless to say
|
||||
that you also need to shut down the server before restoring the
|
||||
data.
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
@ -362,7 +360,18 @@ tar -cf backup.tar /usr/local/pgsql/data
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Also note that the file system backup will not necessarily be
|
||||
An alternative file-system backup approach is to make a
|
||||
<quote>consistent snapshot</quote> of the data directory, if the
|
||||
file system supports that functionality. Such a snapshot will save
|
||||
the database files in a state where the database server was not
|
||||
properly shut down; therefore, when you start the database server
|
||||
on this backed up directory, it will think the server had crashed
|
||||
and replay the WAL log. This is not a problem, just be aware of
|
||||
it.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Note that the file system backup will not necessarily be
|
||||
smaller than an SQL dump. On the contrary, it will most likely be
|
||||
larger. (<application>pg_dump</application> does not need to dump
|
||||
the contents of indexes for example, just the commands to recreate
|
||||
@ -372,7 +381,7 @@ tar -cf backup.tar /usr/local/pgsql/data
|
||||
</sect1>
|
||||
|
||||
<sect1 id="migration">
|
||||
<title>Migration between releases</title>
|
||||
<title>Migration Between Releases</title>
|
||||
|
||||
<indexterm zone="migration">
|
||||
<primary>upgrading</primary>
|
||||
@ -385,17 +394,20 @@ tar -cf backup.tar /usr/local/pgsql/data
|
||||
|
||||
<para>
|
||||
As a general rule, the internal data storage format is subject to
|
||||
change between releases of <productname>PostgreSQL</>. This does not
|
||||
apply to different <quote>patch levels</quote>, these always have
|
||||
compatible storage formats. For example, releases 7.0.1, 7.1.2, and
|
||||
7.2 are not compatible, whereas 7.1.1 and 7.1.2 are. When you
|
||||
update between compatible versions, then you can simply reuse the
|
||||
data area in disk by the new executables. Otherwise you need to
|
||||
change between major releases of <productname>PostgreSQL</> (where
|
||||
the number after the first dot changes). This does not apply to
|
||||
different minor releases under the same major release (where the
|
||||
number of the second dot changes); these always have compatible
|
||||
storage formats. For example, releases 7.0.1, 7.1.2, and 7.2 are
|
||||
not compatible, whereas 7.1.1 and 7.1.2 are. When you update
|
||||
between compatible versions, then you can simply reuse the data
|
||||
area in disk by the new executables. Otherwise you need to
|
||||
<quote>back up</> your data and <quote>restore</> it on the new
|
||||
server, using <application>pg_dump</>. (There are checks in place
|
||||
that prevent you from doing the wrong thing, so no harm can be done
|
||||
by confusing these things.) The precise installation procedure is
|
||||
not subject of this section; these details are in <xref linkend="installation">.
|
||||
not subject of this section; these details are in <xref
|
||||
linkend="installation">.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/charset.sgml,v 2.39 2003/09/11 18:30:38 momjian Exp $ -->
|
||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/charset.sgml,v 2.40 2003/11/04 09:55:38 petere Exp $ -->
|
||||
|
||||
<chapter id="charset">
|
||||
<title>Localization</>
|
||||
@ -248,12 +248,9 @@ initdb --locale=sv_SE
|
||||
<para>
|
||||
Client applications that handle server-side errors by parsing the
|
||||
text of the error message will obviously have problems when the
|
||||
server's messages are in a different language. If you create such
|
||||
an application you need to devise a plan to cope with this
|
||||
situation. The embedded SQL interface (<application>ECPG</>) is
|
||||
also affected by this problem. It is currently recommended that
|
||||
servers interfacing with <application>ECPG</> applications be
|
||||
configured to send messages in English.
|
||||
server's messages are in a different language. Authors of such
|
||||
applications are advised to make use of the error code scheme
|
||||
instead.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@ -430,7 +427,7 @@ initdb --locale=sv_SE
|
||||
mistakenly meant ISO 8859-5. From 7.2 on, <literal>LATIN5</>
|
||||
means ISO 8859-9. If you have a <literal>LATIN5</> database
|
||||
created on 7.1 or earlier and want to migrate to 7.2 or later,
|
||||
you should be very careful about this change.
|
||||
you should be careful about this change.
|
||||
</para>
|
||||
</important>
|
||||
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/client-auth.sgml,v 1.59 2003/09/13 16:43:38 momjian Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/client-auth.sgml,v 1.60 2003/11/04 09:55:38 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="client-authentication">
|
||||
@ -85,13 +85,13 @@ $Header: /cvsroot/pgsql/doc/src/sgml/client-auth.sgml,v 1.59 2003/09/13 16:43:38
|
||||
<para>
|
||||
A record may have one of the seven formats
|
||||
<synopsis>
|
||||
local <replaceable>database</replaceable> <replaceable>user</replaceable> <replaceable>authentication-method</replaceable> <optional><replaceable>authentication-option</replaceable></optional>
|
||||
host <replaceable>database</replaceable> <replaceable>user</replaceable> <replaceable>IP-address</replaceable> <replaceable>IP-mask</replaceable> <replaceable>authentication-method</replaceable> <optional><replaceable>authentication-option</replaceable></optional>
|
||||
hostssl <replaceable>database</replaceable> <replaceable>user</replaceable> <replaceable>IP-address</replaceable> <replaceable>IP-mask</replaceable> <replaceable>authentication-method</replaceable> <optional><replaceable>authentication-option</replaceable></optional>
|
||||
local <replaceable>database</replaceable> <replaceable>user</replaceable> <replaceable>authentication-method</replaceable> <optional><replaceable>authentication-option</replaceable></optional>
|
||||
host <replaceable>database</replaceable> <replaceable>user</replaceable> <replaceable>IP-address</replaceable> <replaceable>IP-mask</replaceable> <replaceable>authentication-method</replaceable> <optional><replaceable>authentication-option</replaceable></optional>
|
||||
hostssl <replaceable>database</replaceable> <replaceable>user</replaceable> <replaceable>IP-address</replaceable> <replaceable>IP-mask</replaceable> <replaceable>authentication-method</replaceable> <optional><replaceable>authentication-option</replaceable></optional>
|
||||
hostnossl <replaceable>database</replaceable> <replaceable>user</replaceable> <replaceable>IP-address</replaceable> <replaceable>IP-mask</replaceable> <replaceable>authentication-method</replaceable> <optional><replaceable>authentication-option</replaceable></optional>
|
||||
host <replaceable>database</replaceable> <replaceable>user</replaceable> <replaceable>IP-address</replaceable>/<replaceable>CIDR-mask</replaceable> <replaceable>authentication-method</replaceable> <optional><replaceable>authentication-option</replaceable></optional>
|
||||
hostssl <replaceable>database</replaceable> <replaceable>user</replaceable> <replaceable>IP-address</replaceable>/<replaceable>CIDR-mask</replaceable> <replaceable>authentication-method</replaceable> <optional><replaceable>authentication-option</replaceable></optional>
|
||||
hostnossl <replaceable>database</replaceable> <replaceable>user</replaceable> <replaceable>IP-address</replaceable>/<replaceable>CIDR-mask</replaceable> <replaceable>authentication-method</replaceable> <optional><replaceable>authentication-option</replaceable></optional>
|
||||
host <replaceable>database</replaceable> <replaceable>user</replaceable> <replaceable>IP-address</replaceable>/<replaceable>IP-masklen</replaceable> <replaceable>authentication-method</replaceable> <optional><replaceable>authentication-option</replaceable></optional>
|
||||
hostssl <replaceable>database</replaceable> <replaceable>user</replaceable> <replaceable>IP-address</replaceable>/<replaceable>IP-masklen</replaceable> <replaceable>authentication-method</replaceable> <optional><replaceable>authentication-option</replaceable></optional>
|
||||
hostnossl <replaceable>database</replaceable> <replaceable>user</replaceable> <replaceable>IP-address</replaceable>/<replaceable>IP-masklen</replaceable> <replaceable>authentication-method</replaceable> <optional><replaceable>authentication-option</replaceable></optional>
|
||||
</synopsis>
|
||||
The meaning of the fields is as follows:
|
||||
|
||||
@ -220,25 +220,26 @@ hostnossl <replaceable>database</replaceable> <replaceable>user</replaceable>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><replaceable>CIDR-mask</replaceable></term>
|
||||
<term><replaceable>IP-masklen</replaceable></term>
|
||||
<listitem>
|
||||
<para>
|
||||
This field may be used as an alternative to the
|
||||
<replaceable>IP-mask</replaceable> notation. It is an
|
||||
integer specifying the number of high-order bits
|
||||
to set in the mask. The number must
|
||||
be between 0 and 32 (in the case of an IPv4 address) or 128
|
||||
(in the case of an IPv6 address) inclusive. 0 will match any
|
||||
address, while 32/128 will match only the exact host specified.
|
||||
The same matching logic is used as for a dotted notation
|
||||
<replaceable>IP-Mask</replaceable>.
|
||||
This field may be used as an alternative to the
|
||||
<replaceable>IP-mask</replaceable> notation. It is an integer
|
||||
specifying the number of high-order bits to set in the mask.
|
||||
The number must be between 0 and 32 (in the case of an IPv4
|
||||
address) or 128 (in the case of an IPv6 address) inclusive. 0
|
||||
will match any address, while 32 (or 128, respectively) will
|
||||
match only the exact host specified. The same matching logic
|
||||
is used as for a dotted notation
|
||||
<replaceable>IP-mask</replaceable>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
There must be no white space between the <replaceable>IP-address</replaceable>
|
||||
and the <literal>/</literal> or the <literal>/</literal> and the
|
||||
<replaceable>CIDR-mask</replaceable>, or the file will not be parsed
|
||||
correctly.
|
||||
There must be no white space between the
|
||||
<replaceable>IP-address</replaceable> and the
|
||||
<literal>/</literal> or the <literal>/</literal> and the
|
||||
<replaceable>IP-masklen</replaceable>, or the file will not be
|
||||
parsed correctly.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/datatype.sgml,v 1.128 2003/11/01 01:56:29 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/datatype.sgml,v 1.129 2003/11/04 09:55:38 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="datatype">
|
||||
@ -917,10 +917,10 @@ CREATE TABLE <replaceable class="parameter">tablename</replaceable> (
|
||||
|
||||
<para>
|
||||
In addition, <productname>PostgreSQL</productname> provides the
|
||||
<type>text</type> type, which stores strings of any
|
||||
length. Although the type <type>text</type> is not in the
|
||||
<acronym>SQL</acronym> standard, several other SQL database products
|
||||
have it as well.
|
||||
<type>text</type> type, which stores strings of any length.
|
||||
Although the type <type>text</type> is not in the
|
||||
<acronym>SQL</acronym> standard, several other SQL database
|
||||
management systems have it as well.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@ -1464,7 +1464,7 @@ SELECT b, char_length(b) FROM test2;
|
||||
</row>
|
||||
<row>
|
||||
<entry>1999-01-08</entry>
|
||||
<entry>ISO-8601, January 8 in any mode
|
||||
<entry>ISO 8601, January 8 in any mode
|
||||
(recommended format)</entry>
|
||||
</row>
|
||||
<row>
|
||||
@ -1486,11 +1486,11 @@ SELECT b, char_length(b) FROM test2;
|
||||
</row>
|
||||
<row>
|
||||
<entry>19990108</entry>
|
||||
<entry>ISO-8601; January 8, 1999 in any mode</entry>
|
||||
<entry>ISO 8601; January 8, 1999 in any mode</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>990108</entry>
|
||||
<entry>ISO-8601; January 8, 1999 in any mode</entry>
|
||||
<entry>ISO 8601; January 8, 1999 in any mode</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>1999.008</entry>
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/ddl.sgml,v 1.21 2003/11/01 01:56:29 petere Exp $ -->
|
||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/ddl.sgml,v 1.22 2003/11/04 09:55:38 petere Exp $ -->
|
||||
|
||||
<chapter id="ddl">
|
||||
<title>Data Definition</title>
|
||||
@ -318,12 +318,12 @@ DROP TABLE products;
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Transaction identifiers are also 32-bit quantities. In a long-lived
|
||||
database it is possible for transaction IDs to wrap around. This
|
||||
is not a fatal problem given appropriate maintenance procedures;
|
||||
see <xref linkend="maintenance"> for details. However, it is
|
||||
unwise to depend on uniqueness of transaction IDs over the long term
|
||||
(more than one billion transactions).
|
||||
Transaction identifiers are also 32-bit quantities. In a
|
||||
long-lived database it is possible for transaction IDs to wrap
|
||||
around. This is not a fatal problem given appropriate maintenance
|
||||
procedures; see <xref linkend="maintenance"> for details. It is
|
||||
unwise, however, to depend on the uniqueness of transaction IDs
|
||||
over the long term (more than one billion transactions).
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/features.sgml,v 2.20 2003/09/20 20:12:04 tgl Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/features.sgml,v 2.21 2003/11/04 09:55:38 petere Exp $
|
||||
-->
|
||||
|
||||
<appendix id="features">
|
||||
@ -30,7 +30,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/features.sgml,v 2.20 2003/09/20 20:12:04 tg
|
||||
|
||||
<para>
|
||||
<acronym>SQL92</acronym> defined three feature sets for conformance:
|
||||
Entry, Intermediate, and Full. Most database products claiming
|
||||
Entry, Intermediate, and Full. Most database management systems claiming
|
||||
<acronym>SQL</acronym> standard conformance were conforming at only
|
||||
the Entry level, since the entire set of features in the
|
||||
Intermediate and Full levels was either too voluminous or in
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/func.sgml,v 1.177 2003/11/01 01:56:29 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/func.sgml,v 1.178 2003/11/04 09:55:38 petere Exp $
|
||||
PostgreSQL documentation
|
||||
-->
|
||||
|
||||
@ -29,10 +29,10 @@ PostgreSQL documentation
|
||||
the functions and operators described in this chapter, with the
|
||||
exception of the most trivial arithmetic and comparison operators
|
||||
and some explicitly marked functions, are not specified by the
|
||||
<acronym>SQL</acronym>
|
||||
standard. Some of the extended functionality is present in other
|
||||
<acronym>SQL</acronym> implementations, and in many cases this
|
||||
functionality is compatible and consistent between various products.
|
||||
<acronym>SQL</acronym> standard. Some of the extended functionality
|
||||
is present in other <acronym>SQL</acronym> database management
|
||||
systems, and in many cases this functionality is compatible and
|
||||
consistent between the various implementations.
|
||||
</para>
|
||||
|
||||
|
||||
@ -7176,7 +7176,7 @@ SELECT pg_type_is_visible('myschema.widget'::regtype);
|
||||
</sect1>
|
||||
|
||||
<sect1 id="functions-array">
|
||||
<title>Array Functions</title>
|
||||
<title>Array Functions and Operators</title>
|
||||
|
||||
<para>
|
||||
<xref linkend="array-operators-table"> shows the operators
|
||||
@ -7578,22 +7578,23 @@ SELECT pg_type_is_visible('myschema.widget'::regtype);
|
||||
|
||||
<note>
|
||||
<para>
|
||||
Users accustomed to working with other RDBMS products may be
|
||||
surprised by the performance characteristics of certain aggregate
|
||||
functions in <productname>PostgreSQL</productname> when the
|
||||
aggregate is applied to the entire table (in other words, no
|
||||
<literal>WHERE</literal> clause is specified). In particular,
|
||||
a query like
|
||||
Users accustomed to working with other SQL database management
|
||||
systems may be surprised by the performance characteristics of
|
||||
certain aggregate functions in
|
||||
<productname>PostgreSQL</productname> when the aggregate is
|
||||
applied to the entire table (in other words, no
|
||||
<literal>WHERE</literal> clause is specified). In particular, a
|
||||
query like
|
||||
<programlisting>
|
||||
SELECT min(col) FROM sometable;
|
||||
</programlisting>
|
||||
will be executed by <productname>PostgreSQL</productname> using a
|
||||
sequential scan of the entire table. Other database systems may
|
||||
optimize queries of this form to use an index on the column, if one
|
||||
is available. Similarly, the aggregate functions
|
||||
<function>max()</function> and <function>count()</function> always
|
||||
require a sequential scan if applied to the entire table in
|
||||
<productname>PostgreSQL</productname>.
|
||||
will be executed by <productname>PostgreSQL</productname> using a
|
||||
sequential scan of the entire table. Other database systems may
|
||||
optimize queries of this form to use an index on the column, if
|
||||
one is available. Similarly, the aggregate functions
|
||||
<function>max()</function> and <function>count()</function> always
|
||||
require a sequential scan if applied to the entire table in
|
||||
<productname>PostgreSQL</productname>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@ -7602,8 +7603,8 @@ SELECT min(col) FROM sometable;
|
||||
queries. Since <function>min()</function>,
|
||||
<function>max()</function>, and <function>count()</function> are
|
||||
defined using a generic API for aggregate functions, there is no
|
||||
provision for <quote>special-casing</quote> the execution of these
|
||||
functions under certain circumstances.
|
||||
provision for special-casing the execution of these functions
|
||||
under certain circumstances.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/install-win32.sgml,v 1.14 2003/09/30 01:26:29 tgl Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/install-win32.sgml,v 1.15 2003/11/04 09:55:38 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="install-win32">
|
||||
@ -109,27 +109,27 @@ $Header: /cvsroot/pgsql/doc/src/sgml/install-win32.sgml,v 1.14 2003/09/30 01:26:
|
||||
|
||||
<para>
|
||||
<application>psql</application> is compiled as a <quote>console
|
||||
application</>. As
|
||||
the Win32 console windows use a different encoding than the rest of the
|
||||
system, you must take special care when using 8-bit characters (eg. German
|
||||
umlauts) at the <application>psql</application> prompt. When
|
||||
<application>psql</application> detects a problematic console codepage, it
|
||||
will warn you at startup. To change the console codepage, two things are
|
||||
neccessary:
|
||||
application</>. As the Win32 console windows use a different
|
||||
encoding than the rest of the system, you must take special care
|
||||
when using 8-bit characters at the <application>psql</application>
|
||||
prompt. When <application>psql</application> detects a problematic
|
||||
console code page, it will warn you at startup. To change the
|
||||
console code page, two things are neccessary:
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
Set the codepage with <userinput>cmd.exe /c chcp 1252</userinput>
|
||||
(1252 is the German value, replace it with your value). If you are using
|
||||
cygwin, you can put this command in <filename>/etc/profile</filename>.
|
||||
Set the code page by entering <userinput>cmd.exe /c chcp
|
||||
1252</userinput>. (1252 is a code page that is appropriate for
|
||||
German; replace it with your value.) If you are using Cygwin,
|
||||
you can put this command in <filename>/etc/profile</filename>.
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
Set the console font to <quote>Lucida Console</>, because the raster font
|
||||
does not work with the ANSI codepage.
|
||||
Set the console font to <quote>Lucida Console</>, because the
|
||||
raster font does not work with the ANSI code page.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/installation.sgml,v 1.177 2003/11/02 12:57:48 petere Exp $ -->
|
||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/installation.sgml,v 1.178 2003/11/04 09:55:38 petere Exp $ -->
|
||||
|
||||
<chapter id="installation">
|
||||
<title><![%standalone-include[<productname>PostgreSQL</>]]>
|
||||
@ -333,7 +333,7 @@ JAVACMD=$JAVA_HOME/bin/java
|
||||
<para>
|
||||
The <productname>PostgreSQL</> &version; sources can be obtained by
|
||||
anonymous FTP from <ulink
|
||||
url="ftp://ftp.postgresql.org/pub/postgresql-&version;.tar.gz"></ulink>.
|
||||
url="ftp://ftp.postgresql.org/pub/source/v&version;/postgresql-&version;.tar.gz"></ulink>.
|
||||
Use a mirror if possible. After you have obtained the file, unpack it:
|
||||
<screen>
|
||||
<userinput>gunzip postgresql-&version;.tar.gz</userinput>
|
||||
@ -637,7 +637,7 @@ JAVACMD=$JAVA_HOME/bin/java
|
||||
<note>
|
||||
<para>
|
||||
Care has been taken to make it possible to install
|
||||
<productname>PostgreSQL</>
|
||||
<productname>PostgreSQL</>
|
||||
into shared installation locations (such as
|
||||
<filename>/usr/local/include</filename>) without interfering
|
||||
with the namespace of the rest of the system. First, the
|
||||
@ -674,7 +674,7 @@ JAVACMD=$JAVA_HOME/bin/java
|
||||
directories that will be added to the list the compiler
|
||||
searches for header files. If you have optional packages
|
||||
(such as GNU <application>Readline</>) installed in a non-standard
|
||||
location,
|
||||
location,
|
||||
you have to use this option and probably also the corresponding
|
||||
<option>--with-libraries</> option.
|
||||
</para>
|
||||
@ -732,8 +732,8 @@ JAVACMD=$JAVA_HOME/bin/java
|
||||
be changed later on, but if you specify it here then both
|
||||
server and clients will have the same default compiled in,
|
||||
which can be very convenient. Usually the only good reason
|
||||
to select a non-default value is if you intend to run multiple
|
||||
<productname>PostgreSQL</> servers on the same machine.
|
||||
to select a non-default value is if you intend to run multiple
|
||||
<productname>PostgreSQL</> servers on the same machine.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -873,8 +873,8 @@ JAVACMD=$JAVA_HOME/bin/java
|
||||
<term><option>--with-pam</option></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Build with <acronym>PAM</><indexterm><primary>PAM</></>
|
||||
(Pluggable Authentication Modules) support.
|
||||
Build with <acronym>PAM</><indexterm><primary>PAM</></>
|
||||
(Pluggable Authentication Modules) support.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -894,7 +894,7 @@ JAVACMD=$JAVA_HOME/bin/java
|
||||
<term><option>--with-rendezvous</option></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Build with Rendezvous support.
|
||||
Build with Rendezvous support.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -903,10 +903,11 @@ JAVACMD=$JAVA_HOME/bin/java
|
||||
<term><option>--disable-spinlocks</option></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Allows source builds to succeed without CPU spinlock support.
|
||||
Lack of spinlock support will produce poor performance.
|
||||
This option is to be used only by platforms lacking
|
||||
spinlock support.
|
||||
Allow the builds to succeed even if PostgreSQL has no CPU
|
||||
spinlock support for the platform. The lack of spinlock
|
||||
support will result in poor performance; therefore, this
|
||||
option should only be used if the build aborts and informs
|
||||
you that the platform lacks spinlock support.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -915,9 +916,10 @@ JAVACMD=$JAVA_HOME/bin/java
|
||||
<term><option>--enable-thread-safety</option></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Allow separate threads in <application>libpq</application>
|
||||
and <application>ECPG</application> programs to safely
|
||||
control their private connection handles.
|
||||
Make the client libraries thread-safe. This allows
|
||||
concurrent threads in <application>libpq</application> and
|
||||
<application>ECPG</application> programs to safely control
|
||||
their private connection handles.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -941,13 +943,13 @@ JAVACMD=$JAVA_HOME/bin/java
|
||||
Compiles all programs and libraries with debugging symbols.
|
||||
This means that you can run the programs through a debugger
|
||||
to analyze problems. This enlarges the size of the installed
|
||||
executables considerably, and on non-GCC compilers it usually
|
||||
also disables compiler optimization, causing slowdowns. However,
|
||||
having the symbols available is extremely helpful for dealing
|
||||
with any problems that may arise. Currently, this option is
|
||||
recommended for production installations only if you use GCC.
|
||||
But you should always have it on if you are doing development work
|
||||
or running a beta version.
|
||||
executables considerably, and on non-GCC compilers it usually
|
||||
also disables compiler optimization, causing slowdowns. However,
|
||||
having the symbols available is extremely helpful for dealing
|
||||
with any problems that may arise. Currently, this option is
|
||||
recommended for production installations only if you use GCC.
|
||||
But you should always have it on if you are doing development work
|
||||
or running a beta version.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -956,16 +958,16 @@ JAVACMD=$JAVA_HOME/bin/java
|
||||
<term><option>--enable-cassert</option></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Enables <firstterm>assertion</> checks in the server, which test for
|
||||
many <quote>can't happen</> conditions. This is invaluable for
|
||||
code development purposes, but the tests slow things down a little.
|
||||
Also, having the tests turned on won't necessarily enhance the
|
||||
stability of your server! The assertion checks are not categorized
|
||||
for severity, and so what might be a relatively harmless bug will
|
||||
still lead to server restarts if it triggers an assertion
|
||||
failure. Currently, this option is not recommended for
|
||||
Enables <firstterm>assertion</> checks in the server, which test for
|
||||
many <quote>can't happen</> conditions. This is invaluable for
|
||||
code development purposes, but the tests slow things down a little.
|
||||
Also, having the tests turned on won't necessarily enhance the
|
||||
stability of your server! The assertion checks are not categorized
|
||||
for severity, and so what might be a relatively harmless bug will
|
||||
still lead to server restarts if it triggers an assertion
|
||||
failure. Currently, this option is not recommended for
|
||||
production use, but you should have it on for development work
|
||||
or when running a beta version.
|
||||
or when running a beta version.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -974,12 +976,12 @@ JAVACMD=$JAVA_HOME/bin/java
|
||||
<term><option>--enable-depend</option></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Enables automatic dependency tracking. With this option, the
|
||||
makefiles are set up so that all affected object files will
|
||||
be rebuilt when any header file is changed. This is useful
|
||||
if you are doing development work, but is just wasted overhead
|
||||
if you intend only to compile once and install. At present,
|
||||
this option will work only if you use GCC.
|
||||
Enables automatic dependency tracking. With this option, the
|
||||
makefiles are set up so that all affected object files will
|
||||
be rebuilt when any header file is changed. This is useful
|
||||
if you are doing development work, but is just wasted overhead
|
||||
if you intend only to compile once and install. At present,
|
||||
this option will work only if you use GCC.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -1040,8 +1042,6 @@ All of PostgreSQL is successfully made. Ready to install.
|
||||
<userinput>gmake check</userinput>
|
||||
</screen>
|
||||
(This won't work as root; do it as an unprivileged user.)
|
||||
It is possible that some tests fail, due to differences in error
|
||||
message wording or floating point results.
|
||||
<![%standalone-include[The file
|
||||
<filename>src/test/regress/README</> and the
|
||||
documentation contain]]>
|
||||
@ -1156,28 +1156,6 @@ All of PostgreSQL is successfully made. Ready to install.
|
||||
<sect1 id="install-post">
|
||||
<title>Post-Installation Setup</title>
|
||||
|
||||
<sect2>
|
||||
<title>Tuning</title>
|
||||
|
||||
<indexterm>
|
||||
<primary>tuning</primary>
|
||||
</indexterm>
|
||||
|
||||
<para>
|
||||
By default, <productname>PostgreSQL</> is configured to run on minimal
|
||||
hardware. This allows it to start up with almost any hardware
|
||||
configuration. However, the default configuration is not designed for
|
||||
optimum performance. To achieve optimum performance, several server
|
||||
variables must be adjusted, the two most common being
|
||||
<varname>shared_buffers</varname> and <varname> sort_mem</varname>
|
||||
mentioned in <![%standalone-include[the documentation]]>
|
||||
<![%standalone-ignore[<xref linkend="runtime-config-resource-memory">]]>.
|
||||
Other parameters in <![%standalone-include[the documentation]]>
|
||||
<![%standalone-ignore[<xref linkend="runtime-config-resource">]]>
|
||||
also affect performance.
|
||||
</para>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Shared Libraries</title>
|
||||
|
||||
@ -1458,39 +1436,28 @@ kill `cat /usr/local/pgsql/data/postmaster.pid`
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
Run the regression tests against the installed server (using the
|
||||
sequential test method). If you didn't run the tests before
|
||||
installation, you should definitely do it now. This is also
|
||||
explained in the documentation.
|
||||
Run the regression tests against the installed server (using
|
||||
<command>gmake installcheck</command>). If you didn't run the
|
||||
tests before installation, you should definitely do it now. This
|
||||
is also explained in the documentation.
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
By default, <productname>PostgreSQL</> is configured to run on
|
||||
minimal hardware. This allows it to start up with almost any
|
||||
hardware configuration. The default configuration is, however,
|
||||
not designed for optimum performance. To achieve optimum
|
||||
performance, several server parameters must be adjusted, the two
|
||||
most common being <varname>shared_buffers</varname> and
|
||||
<varname> sort_mem</varname> mentioned in the documentation.
|
||||
Other parameters mentioned in the documentation also affect
|
||||
performance.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
|
||||
<!-- do we still ship this? -->
|
||||
<!--
|
||||
<para>
|
||||
The documentation is also available in Postscript format. If you
|
||||
have a Postscript printer, or have your machine already set up to
|
||||
accept Postscript files using a print filter, then to print, the
|
||||
documentation simply type
|
||||
<programlisting>
|
||||
cd /usr/local/pgsql/doc
|
||||
gunzip -c postgres.ps.gz | lpr
|
||||
</programlisting>
|
||||
Here is how you might do it if you have <productname>Ghostscript</>
|
||||
installed on your system and are writing to a Laserjet printer.
|
||||
<programlisting>
|
||||
gunzip -c postgres.ps.gz \
|
||||
| gs -sDEVICE=laserjet -r300 -q -dNOPAUSE -sOutputFile=- \
|
||||
| lpr
|
||||
</programlisting>
|
||||
Printer setups can vary wildly from system to system. If in doubt,
|
||||
consult your manuals or your local expert.
|
||||
</para>
|
||||
-->
|
||||
|
||||
</sect1>
|
||||
]]>
|
||||
|
||||
@ -1519,194 +1486,186 @@ gunzip -c postgres.ps.gz \
|
||||
<tgroup cols="5">
|
||||
<thead>
|
||||
<row>
|
||||
<entry><acronym>OS</acronym></entry>
|
||||
<entry>Processor</entry>
|
||||
<entry>Version</entry>
|
||||
<entry>Reported</entry>
|
||||
<entry>Remarks</entry>
|
||||
<entry><acronym>OS</acronym></entry>
|
||||
<entry>Processor</entry>
|
||||
<entry>Version</entry>
|
||||
<entry>Reported</entry>
|
||||
<entry>Remarks</entry>
|
||||
</row>
|
||||
</thead>
|
||||
<tbody>
|
||||
<row>
|
||||
<entry><systemitem class="osname">AIX</></entry>
|
||||
<entry><systemitem>RS6000</></entry>
|
||||
<entry>7.4</entry>
|
||||
<entry>2003-10-25,
|
||||
Hans-Jürgen Schönig (<email>hs@cybertec.at</email>)</entry>
|
||||
<entry><systemitem class="osname">AIX</></entry>
|
||||
<entry><systemitem>RS6000</></entry>
|
||||
<entry>7.4</entry>
|
||||
<entry>2003-10-25,
|
||||
Hans-Jürgen Schönig (<email>hs@cybertec.at</email>)</entry>
|
||||
<entry>see also <filename>doc/FAQ_AIX</filename></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><systemitem class="osname">BSD/OS</></entry>
|
||||
<entry><systemitem>x86</></entry>
|
||||
<entry>7.4</entry>
|
||||
<entry>2003-10-24,
|
||||
Bruce Momjian (<email>pgman@candle.pha.pa.us</email>)</entry>
|
||||
<entry><systemitem class="osname">BSD/OS</></entry>
|
||||
<entry><systemitem>x86</></entry>
|
||||
<entry>7.4</entry>
|
||||
<entry>2003-10-24,
|
||||
Bruce Momjian (<email>pgman@candle.pha.pa.us</email>)</entry>
|
||||
<entry>4.3</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><systemitem class="osname">FreeBSD</></entry>
|
||||
<entry><systemitem>Alpha</></entry>
|
||||
<entry>7.4</entry>
|
||||
<entry>2003-10-25,
|
||||
Peter Eisentraut (<email>peter_e@gmx.net</email>)</entry>
|
||||
<entry><systemitem class="osname">FreeBSD</></entry>
|
||||
<entry><systemitem>Alpha</></entry>
|
||||
<entry>7.4</entry>
|
||||
<entry>2003-10-25,
|
||||
Peter Eisentraut (<email>peter_e@gmx.net</email>)</entry>
|
||||
<entry>4.8</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><systemitem class="osname">FreeBSD</></entry>
|
||||
<entry><systemitem>x86</></entry>
|
||||
<entry>7.4</entry>
|
||||
<entry>2003-10-24,
|
||||
Peter Eisentraut (<email>peter_e@gmx.net</email>)</entry>
|
||||
<entry><systemitem class="osname">FreeBSD</></entry>
|
||||
<entry><systemitem>x86</></entry>
|
||||
<entry>7.4</entry>
|
||||
<entry>2003-10-24,
|
||||
Peter Eisentraut (<email>peter_e@gmx.net</email>)</entry>
|
||||
<entry>4.9</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><systemitem class="osname">HP-UX</></entry>
|
||||
<entry><systemitem>PA-RISC</></entry>
|
||||
<entry>7.4</entry>
|
||||
<entry><systemitem class="osname">HP-UX</></entry>
|
||||
<entry><systemitem>PA-RISC</></entry>
|
||||
<entry>7.4</entry>
|
||||
<entry>2003-10-31,
|
||||
10.20 Tom Lane (<email>tgl@sss.pgh.pa.us</email>)
|
||||
10.20 Tom Lane (<email>tgl@sss.pgh.pa.us</email>)
|
||||
</entry>
|
||||
<entry><command>gcc</> and <command>cc</>; see also <filename>doc/FAQ_HPUX</filename></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><systemitem class="osname">IRIX</></entry>
|
||||
<entry><systemitem>MIPS</></entry>
|
||||
<entry>7.3</entry>
|
||||
<entry>2002-10-27,
|
||||
Ian Barwick (<email>barwick@gmx.net</email>)</entry>
|
||||
<entry>Irix64 Komma 6.5</entry>
|
||||
<entry><systemitem class="osname">IRIX</></entry>
|
||||
<entry><systemitem>MIPS</></entry>
|
||||
<entry>7.3</entry>
|
||||
<entry>2002-10-27,
|
||||
Ian Barwick (<email>barwick@gmx.net</email>)</entry>
|
||||
<entry>Irix64 Komma 6.5</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><systemitem class="osname">Linux</></entry>
|
||||
<entry><systemitem>Alpha</></entry>
|
||||
<entry>7.4</entry>
|
||||
<entry>2003-10-25,
|
||||
Noèl Köthe (<email>noel@debian.org</email>)</entry>
|
||||
<entry>2.4</entry>
|
||||
<entry><systemitem class="osname">Linux</></entry>
|
||||
<entry><systemitem>Alpha</></entry>
|
||||
<entry>7.4</entry>
|
||||
<entry>2003-10-25,
|
||||
Noèl Köthe (<email>noel@debian.org</email>)</entry>
|
||||
<entry>2.4</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><systemitem class="osname">Linux</></entry>
|
||||
<entry><systemitem>arm41</></entry>
|
||||
<entry>7.4</entry>
|
||||
<entry>2003-10-25,
|
||||
Noèl Köthe (<email>noel@debian.org</email>)</entry>
|
||||
<entry>2.4</entry>
|
||||
<entry><systemitem class="osname">Linux</></entry>
|
||||
<entry><systemitem>arm41</></entry>
|
||||
<entry>7.4</entry>
|
||||
<entry>2003-10-25,
|
||||
Noèl Köthe (<email>noel@debian.org</email>)</entry>
|
||||
<entry>2.4</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><systemitem class="osname">Linux</></entry>
|
||||
<entry><systemitem>Itanium</></entry>
|
||||
<entry>7.4</entry>
|
||||
<entry>2003-10-25,
|
||||
Noèl Köthe (<email>noel@debian.org</email>)</entry>
|
||||
<entry>2.4</entry>
|
||||
<entry><systemitem class="osname">Linux</></entry>
|
||||
<entry><systemitem>Itanium</></entry>
|
||||
<entry>7.4</entry>
|
||||
<entry>2003-10-25,
|
||||
Noèl Köthe (<email>noel@debian.org</email>)</entry>
|
||||
<entry>2.4</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><systemitem class="osname">Linux</></entry>
|
||||
<entry><systemitem>m68k</></entry>
|
||||
<entry>7.4</entry>
|
||||
<entry>2003-10-25,
|
||||
Noèl Köthe (<email>noel@debian.org</email>)</entry>
|
||||
<entry>2.4</entry>
|
||||
<entry><systemitem class="osname">Linux</></entry>
|
||||
<entry><systemitem>m68k</></entry>
|
||||
<entry>7.4</entry>
|
||||
<entry>2003-10-25,
|
||||
Noèl Köthe (<email>noel@debian.org</email>)</entry>
|
||||
<entry>2.4</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><systemitem class="osname">Linux</></entry>
|
||||
<entry><systemitem>MIPS</></entry>
|
||||
<entry>7.4</entry>
|
||||
<entry>2003-10-25,
|
||||
Noèl Köthe (<email>noel@debian.org</email>)</entry>
|
||||
<entry>2.4</entry>
|
||||
<entry><systemitem class="osname">Linux</></entry>
|
||||
<entry><systemitem>MIPS</></entry>
|
||||
<entry>7.4</entry>
|
||||
<entry>2003-10-25,
|
||||
Noèl Köthe (<email>noel@debian.org</email>)</entry>
|
||||
<entry>2.4</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><systemitem class="osname">Linux</></entry>
|
||||
<entry><systemitem>Opteron</></entry>
|
||||
<entry>7.4</entry>
|
||||
<entry>2003-11-01,
|
||||
Jani Averbach (<email>jaa@cc.jyu.fi</email>)</entry>
|
||||
<entry>2.6</entry>
|
||||
<entry><systemitem class="osname">Linux</></entry>
|
||||
<entry><systemitem>Opteron</></entry>
|
||||
<entry>7.4</entry>
|
||||
<entry>2003-11-01,
|
||||
Jani Averbach (<email>jaa@cc.jyu.fi</email>)</entry>
|
||||
<entry>2.6</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><systemitem class="osname">Linux</></entry>
|
||||
<entry><systemitem>PlayStation 2</></entry>
|
||||
<entry>7.3</entry>
|
||||
<entry>2002-11-19,
|
||||
Permaine Cheung <email>pcheung@redhat.com</email>)</entry>
|
||||
<entry><literal>#undef HAS_TEST_AND_SET</>, remove <type>slock_t</> <literal>typedef</></entry>
|
||||
<entry><systemitem class="osname">Linux</></entry>
|
||||
<entry><systemitem>PPC</></entry>
|
||||
<entry>7.4</entry>
|
||||
<entry>2003-10-25,
|
||||
Noèl Köthe (<email>noel@debian.org</email>)</entry>
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><systemitem class="osname">Linux</></entry>
|
||||
<entry><systemitem>PPC</></entry>
|
||||
<entry>7.4</entry>
|
||||
<entry>2003-10-25,
|
||||
Noèl Köthe (<email>noel@debian.org</email>)</entry>
|
||||
<entry></entry>
|
||||
<entry><systemitem class="osname">Linux</></entry>
|
||||
<entry><systemitem>S/390</></entry>
|
||||
<entry>7.4</entry>
|
||||
<entry>2003-10-25,
|
||||
Noèl Köthe (<email>noel@debian.org</email>)</entry>
|
||||
<entry>2.4</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><systemitem class="osname">Linux</></entry>
|
||||
<entry><systemitem>S/390</></entry>
|
||||
<entry>7.4</entry>
|
||||
<entry>2003-10-25,
|
||||
Noèl Köthe (<email>noel@debian.org</email>)</entry>
|
||||
<entry>2.4</entry>
|
||||
<entry><systemitem class="osname">Linux</></entry>
|
||||
<entry><systemitem>Sparc</></entry>
|
||||
<entry>7.4</entry>
|
||||
<entry>2003-10-24,
|
||||
Peter Eisentraut (<email>peter_e@gmx.net</email>)</entry>
|
||||
<entry>2.4, 32-bit</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><systemitem class="osname">Linux</></entry>
|
||||
<entry><systemitem>Sparc</></entry>
|
||||
<entry>7.4</entry>
|
||||
<entry>2003-10-24,
|
||||
Peter Eisentraut (<email>peter_e@gmx.net</email>)</entry>
|
||||
<entry>2.4, 32-bit</entry>
|
||||
<entry><systemitem class="osname">Linux</></entry>
|
||||
<entry><systemitem>x86</></entry>
|
||||
<entry>7.4</entry>
|
||||
<entry>2003-10-24,
|
||||
Peter Eisentraut (<email>peter_e@gmx.net</email>)</entry>
|
||||
<entry>2.4</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><systemitem class="osname">Linux</></entry>
|
||||
<entry><systemitem>x86</></entry>
|
||||
<entry>7.4</entry>
|
||||
<entry>2003-10-24,
|
||||
Peter Eisentraut (<email>peter_e@gmx.net</email>)</entry>
|
||||
<entry>2.4</entry>
|
||||
<entry><systemitem class="osname">MacOS X</></entry>
|
||||
<entry><systemitem>PPC</></entry>
|
||||
<entry>7.4</entry>
|
||||
<entry>2003-10-24,
|
||||
10.2.8, Adam Witney (<email>awitney@sghms.ac.uk</email>),
|
||||
10.3, Marko Karppinen (<email>marko@karppinen.fi</email>)</entry>
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><systemitem class="osname">MacOS X</></entry>
|
||||
<entry><systemitem>PPC</></entry>
|
||||
<entry>7.4</entry>
|
||||
<entry>2003-10-24,
|
||||
10.2.8, Adam Witney (<email>awitney@sghms.ac.uk</email>),
|
||||
10.3, Marko Karppinen (<email>marko@karppinen.fi</email>)</entry>
|
||||
<entry></entry>
|
||||
<entry><systemitem class="osname">NetBSD</></entry>
|
||||
<entry><systemitem>arm32</></entry>
|
||||
<entry>7.3</entry>
|
||||
<entry>2002-11-19,
|
||||
Patrick Welche (<email>prlw1@newn.cam.ac.uk</email>)</entry>
|
||||
<entry>1.6</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><systemitem class="osname">NetBSD</></entry>
|
||||
<entry><systemitem>arm32</></entry>
|
||||
<entry>7.3</entry>
|
||||
<entry>2002-11-19,
|
||||
Patrick Welche (<email>prlw1@newn.cam.ac.uk</email>)</entry>
|
||||
<entry>1.6</entry>
|
||||
<entry><systemitem class="osname">NetBSD</></entry>
|
||||
<entry><systemitem>x86</></entry>
|
||||
<entry>7.4</entry>
|
||||
<entry>2003-10-24,
|
||||
Peter Eisentraut (<email>peter_e@gmx.net</email>)</entry>
|
||||
<entry>1.6</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><systemitem class="osname">NetBSD</></entry>
|
||||
<entry><systemitem>x86</></entry>
|
||||
<entry>7.4</entry>
|
||||
<entry>2003-10-24,
|
||||
Peter Eisentraut (<email>peter_e@gmx.net</email>)</entry>
|
||||
<entry>1.6</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><systemitem class="osname">OpenBSD</></entry>
|
||||
<entry><systemitem>Sparc</></entry>
|
||||
<entry>7.4</entry>
|
||||
<entry>2003-11-01,
|
||||
Peter Eisentraut (<email>peter_e@gmx.net</email>)</entry>
|
||||
<entry><systemitem class="osname">OpenBSD</></entry>
|
||||
<entry><systemitem>Sparc</></entry>
|
||||
<entry>7.4</entry>
|
||||
<entry>2003-11-01,
|
||||
Peter Eisentraut (<email>peter_e@gmx.net</email>)</entry>
|
||||
<entry>3.4</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><systemitem class="osname">OpenBSD</></entry>
|
||||
<entry><systemitem>x86</></entry>
|
||||
<entry>7.4</entry>
|
||||
<entry>2003-10-24,
|
||||
Peter Eisentraut (<email>peter_e@gmx.net</email>)</entry>
|
||||
<entry><systemitem class="osname">OpenBSD</></entry>
|
||||
<entry><systemitem>x86</></entry>
|
||||
<entry>7.4</entry>
|
||||
<entry>2003-10-24,
|
||||
Peter Eisentraut (<email>peter_e@gmx.net</email>)</entry>
|
||||
<entry>3.2</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><systemitem class="osname">SCO OpenServer 5</></entry>
|
||||
<entry><systemitem class="osname">SCO OpenServer</></entry>
|
||||
<entry><systemitem>x86</></entry>
|
||||
<entry>7.3.1</entry>
|
||||
<entry>2002-12-11,
|
||||
@ -1714,45 +1673,45 @@ gunzip -c postgres.ps.gz \
|
||||
<entry>5.0.4, <command>gcc</>; see also <filename>doc/FAQ_SCO</filename></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><systemitem class="osname">Solaris</></entry>
|
||||
<entry><systemitem>Sparc</></entry>
|
||||
<entry>7.4</entry>
|
||||
<entry>2003-10-26,
|
||||
Christopher Browne (<email>cbbrowne@libertyrms.info</email>)</entry>
|
||||
<entry>2.8; see also <filename>doc/FAQ_Solaris</filename></entry>
|
||||
<entry><systemitem class="osname">Solaris</></entry>
|
||||
<entry><systemitem>Sparc</></entry>
|
||||
<entry>7.4</entry>
|
||||
<entry>2003-10-26,
|
||||
Christopher Browne (<email>cbbrowne@libertyrms.info</email>)</entry>
|
||||
<entry>2.8; see also <filename>doc/FAQ_Solaris</filename></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><systemitem class="osname">Solaris</></entry>
|
||||
<entry><systemitem>x86</></entry>
|
||||
<entry>7.4</entry>
|
||||
<entry>2003-10-26,
|
||||
Kurt Roeckx (<email>Q@ping.be</email>)</entry>
|
||||
<entry>2.6 see also <filename>doc/FAQ_Solaris</filename></entry>
|
||||
<entry><systemitem class="osname">Solaris</></entry>
|
||||
<entry><systemitem>x86</></entry>
|
||||
<entry>7.4</entry>
|
||||
<entry>2003-10-26,
|
||||
Kurt Roeckx (<email>Q@ping.be</email>)</entry>
|
||||
<entry>2.6 see also <filename>doc/FAQ_Solaris</filename></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><systemitem class="osname">Tru64 UNIX</></entry>
|
||||
<entry><systemitem>Alpha</></entry>
|
||||
<entry>7.4</entry>
|
||||
<entry>2003-10-25,
|
||||
5.1b Peter Eisentraut (<email>peter_e@gmx.net</email>),
|
||||
4.0g Alessio Bragadini (<email>alessio@albourne.com</email>)</entry>
|
||||
<entry><systemitem class="osname">Tru64 UNIX</></entry>
|
||||
<entry><systemitem>Alpha</></entry>
|
||||
<entry>7.4</entry>
|
||||
<entry>2003-10-25,
|
||||
5.1b Peter Eisentraut (<email>peter_e@gmx.net</email>),
|
||||
4.0g Alessio Bragadini (<email>alessio@albourne.com</email>)</entry>
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><systemitem class="osname">UnixWare</></entry>
|
||||
<entry><systemitem>x86</></entry>
|
||||
<entry>7.3</entry>
|
||||
<entry>2002-11-01,
|
||||
7.1.3 Larry Rosenman (<email>ler@lerctr.org</email>),
|
||||
7.1.1 and 7.1.2(8.0.0) Olivier Prenant (<email>ohp@pyrenet.fr</email>)</entry>
|
||||
<entry>see also <filename>doc/FAQ_SCO</filename></entry>
|
||||
<entry><systemitem class="osname">UnixWare</></entry>
|
||||
<entry><systemitem>x86</></entry>
|
||||
<entry>7.3</entry>
|
||||
<entry>2002-11-01,
|
||||
7.1.3 Larry Rosenman (<email>ler@lerctr.org</email>),
|
||||
7.1.1 and 7.1.2(8.0.0) Olivier Prenant (<email>ohp@pyrenet.fr</email>)</entry>
|
||||
<entry>see also <filename>doc/FAQ_SCO</filename></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><systemitem class="osname">Windows with <application>Cygwin</application></></entry>
|
||||
<entry><systemitem>x86</></entry>
|
||||
<entry>7.4</entry>
|
||||
<entry>2003-10-24,
|
||||
Peter Eisentraut (<email>peter_e@gmx.net</email>)</entry>
|
||||
<entry><systemitem class="osname">Windows with <application>Cygwin</application></></entry>
|
||||
<entry><systemitem>x86</></entry>
|
||||
<entry>7.4</entry>
|
||||
<entry>2003-10-24,
|
||||
Peter Eisentraut (<email>peter_e@gmx.net</email>)</entry>
|
||||
<entry>see <filename>doc/FAQ_MSWIN</filename></entry>
|
||||
</row>
|
||||
<row>
|
||||
@ -1804,6 +1763,26 @@ gunzip -c postgres.ps.gz \
|
||||
Cyril Velter (<email>cyril.velter@libertysurf.fr</email>)</entry>
|
||||
<entry>needs updates to semaphore code</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><systemitem class="osname">Linux</></entry>
|
||||
<entry><systemitem>PlayStation 2</></entry>
|
||||
<entry>7.4</entry>
|
||||
<entry>2003-11-02,
|
||||
Peter Eisentraut <email>peter_e@gmx.net</email>)</entry>
|
||||
<entry>
|
||||
needs new <filename>config.guess</filename>,
|
||||
<option>--disable-spinlock</option>, <literal>#undef
|
||||
HAS_TEST_AND_SET</>, disable <function>tas_dummy()</>
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><systemitem class="osname">Linux</></entry>
|
||||
<entry><systemitem>PA-RISC</></entry>
|
||||
<entry>7.4</entry>
|
||||
<entry>2003-10-25,
|
||||
Noèl Köthe (<email>noel@debian.org</email>)</entry>
|
||||
<entry>needs <option>--disable-spinlock</option>, otherwise OK</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><systemitem class="osname">NetBSD</></entry>
|
||||
<entry><systemitem>Alpha</></entry>
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/maintenance.sgml,v 1.27 2003/11/01 01:56:29 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/maintenance.sgml,v 1.28 2003/11/04 09:55:38 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="maintenance">
|
||||
@ -40,10 +40,10 @@ $Header: /cvsroot/pgsql/doc/src/sgml/maintenance.sgml,v 1.27 2003/11/01 01:56:29
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<productname>PostgreSQL</productname> is low-maintenance compared to
|
||||
some other database products. Nonetheless, appropriate attention to
|
||||
these tasks will go far towards ensuring a pleasant and productive
|
||||
experience with the system.
|
||||
<productname>PostgreSQL</productname> is low-maintenance compared
|
||||
to some other database management systems. Nonetheless,
|
||||
appropriate attention to these tasks will go far towards ensuring a
|
||||
pleasant and productive experience with the system.
|
||||
</para>
|
||||
|
||||
<sect1 id="routine-vacuuming">
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/monitoring.sgml,v 1.23 2003/11/01 01:56:29 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/monitoring.sgml,v 1.24 2003/11/04 09:55:38 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="monitoring">
|
||||
@ -367,12 +367,13 @@ postgres: <replaceable>user</> <replaceable>database</> <replaceable>host</> <re
|
||||
queries that use the same underlying statistics access functions as
|
||||
these standard views do. These functions are listed in <xref
|
||||
linkend="monitoring-stats-funcs-table">. The per-database access
|
||||
functions take a database OID as argument to identify which database to
|
||||
report on. The per-table and per-index functions take a table or
|
||||
index OID. (Note that only tables and indexes in the current
|
||||
database can be seen with these functions.) The per-backend access
|
||||
functions take a backend ID number, which ranges from one to the
|
||||
number of currently active backend processes.
|
||||
functions take a database OID as argument to identify which
|
||||
database to report on. The per-table and per-index functions take
|
||||
a table or index OID. (Note that only tables and indexes in the
|
||||
current database can be seen with these functions.) The
|
||||
per-backend process access functions take a backend process ID
|
||||
number, which ranges from one to the number of currently active
|
||||
backend processes.
|
||||
</para>
|
||||
|
||||
<table id="monitoring-stats-funcs-table">
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/mvcc.sgml,v 2.39 2003/10/17 22:38:20 tgl Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/mvcc.sgml,v 2.40 2003/11/04 09:55:38 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="mvcc">
|
||||
@ -770,22 +770,17 @@ UPDATE accounts SET balance = balance - 100.00 WHERE acctnum = 22222;
|
||||
|
||||
<para>
|
||||
To ensure the current validity of a row and protect it against
|
||||
concurrent updates one must use <command>SELECT FOR UPDATE</command> or
|
||||
an appropriate <command>LOCK TABLE</command> statement.
|
||||
(<command>SELECT FOR UPDATE</command> locks just the returned rows against
|
||||
concurrent updates, while <command>LOCK TABLE</command> locks the
|
||||
whole table.)
|
||||
This should be taken into account when porting applications to
|
||||
concurrent updates one must use <command>SELECT FOR
|
||||
UPDATE</command> or an appropriate <command>LOCK TABLE</command>
|
||||
statement. (<command>SELECT FOR UPDATE</command> locks just the
|
||||
returned rows against concurrent updates, while <command>LOCK
|
||||
TABLE</command> locks the whole table.) This should be taken into
|
||||
account when porting applications to
|
||||
<productname>PostgreSQL</productname> from other environments.
|
||||
|
||||
<note>
|
||||
<para>
|
||||
Before version 6.5 <productname>PostgreSQL</productname> used
|
||||
read locks, and so the above consideration is also the case when
|
||||
upgrading from <productname>PostgreSQL</productname> versions
|
||||
prior to 6.5.
|
||||
</para>
|
||||
</note>
|
||||
(Before version 6.5 <productname>PostgreSQL</productname> used
|
||||
read locks, and so this above consideration is also relevant when
|
||||
upgrading from <productname>PostgreSQL</productname> versions
|
||||
prior to 6.5.)
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/postgres.sgml,v 1.59 2003/10/23 13:58:43 tgl Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/postgres.sgml,v 1.60 2003/11/04 09:55:38 petere Exp $
|
||||
-->
|
||||
|
||||
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook V3.1//EN" [
|
||||
@ -84,7 +84,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/postgres.sgml,v 1.59 2003/10/23 13:58:43 tg
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Readers of this book should know how to connect to a
|
||||
Readers of this part should know how to connect to a
|
||||
<productname>PostgreSQL</> database and issue
|
||||
<acronym>SQL</acronym> commands. Readers that are unfamiliar with
|
||||
these issues are encouraged to read <xref linkend="tutorial">
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/queries.sgml,v 1.25 2003/11/01 01:56:29 petere Exp $ -->
|
||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/queries.sgml,v 1.26 2003/11/04 09:55:38 petere Exp $ -->
|
||||
|
||||
<chapter id="queries">
|
||||
<title>Queries</title>
|
||||
@ -105,7 +105,7 @@ SELECT random();
|
||||
</para>
|
||||
|
||||
<sect2 id="queries-from">
|
||||
<title>The FROM Clause</title>
|
||||
<title>The <literal>FROM</literal> Clause</title>
|
||||
|
||||
<para>
|
||||
The <literal>FROM</> clause derives a table from one or more other
|
||||
@ -670,7 +670,7 @@ SELECT *
|
||||
</sect2>
|
||||
|
||||
<sect2 id="queries-where">
|
||||
<title>The WHERE Clause</title>
|
||||
<title>The <literal>WHERE</literal> Clause</title>
|
||||
|
||||
<indexterm zone="queries-where">
|
||||
<primary>WHERE</primary>
|
||||
@ -716,7 +716,7 @@ FROM a NATURAL JOIN b WHERE b.val > 5
|
||||
</programlisting>
|
||||
Which one of these you use is mainly a matter of style. The
|
||||
<literal>JOIN</> syntax in the <literal>FROM</> clause is
|
||||
probably not as portable to other SQL database products. For
|
||||
probably not as portable to other SQL database management systems. For
|
||||
outer joins there is no choice in any case: they must be done in
|
||||
the <literal>FROM</> clause. An <literal>ON</>/<literal>USING</>
|
||||
clause of an outer join is <emphasis>not</> equivalent to a
|
||||
@ -758,7 +758,7 @@ SELECT ... FROM fdt WHERE EXISTS (SELECT c1 FROM t2 WHERE c2 > fdt.c1)
|
||||
|
||||
|
||||
<sect2 id="queries-group">
|
||||
<title>The GROUP BY and HAVING Clauses</title>
|
||||
<title>The <literal>GROUP BY</literal> and <literal>HAVING</literal> Clauses</title>
|
||||
|
||||
<indexterm zone="queries-group">
|
||||
<primary>GROUP BY</primary>
|
||||
@ -1040,7 +1040,7 @@ SELECT a AS value, b + c AS sum FROM ...
|
||||
</sect2>
|
||||
|
||||
<sect2 id="queries-distinct">
|
||||
<title>DISTINCT</title>
|
||||
<title><literal>DISTINCT</literal></title>
|
||||
|
||||
<indexterm zone="queries-distinct">
|
||||
<primary>DISTINCT</primary>
|
||||
@ -1264,7 +1264,7 @@ SELECT a AS b FROM table1 ORDER BY a;
|
||||
|
||||
|
||||
<sect1 id="queries-limit">
|
||||
<title>LIMIT and OFFSET</title>
|
||||
<title><literal>LIMIT</literal> and <literal>OFFSET</literal></title>
|
||||
|
||||
<indexterm zone="queries-limit">
|
||||
<primary>LIMIT</primary>
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/pg_dump.sgml,v 1.65 2003/09/23 22:48:53 tgl Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/pg_dump.sgml,v 1.66 2003/11/04 09:55:39 petere Exp $
|
||||
PostgreSQL documentation
|
||||
-->
|
||||
|
||||
@ -177,7 +177,7 @@ PostgreSQL documentation
|
||||
Dump data as <command>INSERT</command> commands (rather
|
||||
than <command>COPY</command>). This will make restoration very
|
||||
slow, but it makes the archives more portable to other SQL database
|
||||
packages.
|
||||
management systems.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/pg_dumpall.sgml,v 1.41 2003/11/02 12:58:39 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/pg_dumpall.sgml,v 1.42 2003/11/04 09:55:39 petere Exp $
|
||||
PostgreSQL documentation
|
||||
-->
|
||||
|
||||
@ -112,7 +112,7 @@ PostgreSQL documentation
|
||||
Dump data as <command>INSERT</command> commands (rather
|
||||
than <command>COPY</command>). This will make restoration very
|
||||
slow, but it makes the output more portable to other SQL database
|
||||
packages.
|
||||
management systems.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/regress.sgml,v 1.35 2003/11/02 21:56:14 tgl Exp $ -->
|
||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/regress.sgml,v 1.36 2003/11/04 09:55:38 petere Exp $ -->
|
||||
|
||||
<chapter id="regress">
|
||||
<title id="regress-title">Regression Tests</title>
|
||||
@ -60,7 +60,6 @@ gmake check
|
||||
linkend="regress-evaluation"> below for more.
|
||||
</para>
|
||||
|
||||
<note>
|
||||
<para>
|
||||
Because this test method runs a temporary server, it will not work
|
||||
when you are the root user (since the server will not start as root).
|
||||
@ -82,9 +81,7 @@ gmake check
|
||||
<para>
|
||||
Alternatively, run the tests after installation.
|
||||
</para>
|
||||
</note>
|
||||
|
||||
<tip>
|
||||
<para>
|
||||
The parallel regression test starts quite a few processes under your
|
||||
user ID. Presently, the maximum concurrency is twenty parallel test
|
||||
@ -101,9 +98,7 @@ gmake MAX_CONNECTIONS=10 check
|
||||
</screen>
|
||||
runs no more than ten tests concurrently.
|
||||
</para>
|
||||
</tip>
|
||||
|
||||
<tip>
|
||||
<para>
|
||||
On some systems, the default Bourne-compatible shell
|
||||
(<filename>/bin/sh</filename>) gets confused when it has to manage
|
||||
@ -116,7 +111,6 @@ gmake SHELL=/bin/ksh check
|
||||
If no non-broken shell is available, you may be able to work around the
|
||||
problem by limiting the number of connections, as shown above.
|
||||
</para>
|
||||
</tip>
|
||||
|
||||
<para>
|
||||
To run the tests after installation<![%standalone-ignore;[ (see <xref linkend="installation">)]]>,
|
||||
@ -223,9 +217,9 @@ gmake installcheck
|
||||
|
||||
<note>
|
||||
<para>
|
||||
Because USA daylight-saving rules are used, this problem always
|
||||
Because USA daylight-saving time rules are used, this problem always
|
||||
occurs on the first Sunday of April, the last Sunday of October,
|
||||
and their following Mondays, regardless of when daylight-saving
|
||||
and their following Mondays, regardless of when daylight-saving time
|
||||
is in effect where you live. Also note that the problem appears or
|
||||
disappears at midnight Pacific time (UTC-7 or UTC-8), not midnight
|
||||
your local time. Thus the failure may appear late on Saturday or
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/runtime.sgml,v 1.215 2003/11/01 01:56:29 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/runtime.sgml,v 1.216 2003/11/04 09:55:38 petere Exp $
|
||||
-->
|
||||
|
||||
<Chapter Id="runtime">
|
||||
@ -174,7 +174,7 @@ $ <userinput>postmaster -D /usr/local/pgsql/data</userinput>
|
||||
To start the <command>postmaster</command> in the
|
||||
background, use the usual shell syntax:
|
||||
<screen>
|
||||
$ <userinput>postmaster -D /usr/local/pgsql/data > logfile 2>&1 &</userinput>
|
||||
$ <userinput>postmaster -D /usr/local/pgsql/data >logfile 2>&1 &</userinput>
|
||||
</screen>
|
||||
It is an important to store the server's <systemitem>stdout</> and
|
||||
<systemitem>stderr</> output somewhere, as shown above. It will help
|
||||
@ -344,7 +344,7 @@ FATAL: could not create TCP/IP listen socket
|
||||
A message like
|
||||
<screen>
|
||||
FATAL: could not create shared memory segment: Invalid argument
|
||||
DETAIL: Failed syscall was shmget(key=5440001, size=4011376640, 03600).
|
||||
DETAIL: Failed system call was shmget(key=5440001, size=4011376640, 03600).
|
||||
</screen>
|
||||
probably means your kernel's limit on the size of shared memory is
|
||||
smaller than the work area <productname>PostgreSQL</productname>
|
||||
@ -363,7 +363,7 @@ DETAIL: Failed syscall was shmget(key=5440001, size=4011376640, 03600).
|
||||
An error like
|
||||
<screen>
|
||||
FATAL: could not create semaphores: No space left on device
|
||||
DETAIL: Failed syscall was semget(5440126, 17, 03600).
|
||||
DETAIL: Failed system call was semget(5440126, 17, 03600).
|
||||
</screen>
|
||||
does <emphasis>not</emphasis> mean you've run out of disk
|
||||
space. It means your kernel's limit on the number of <systemitem
|
||||
@ -1572,7 +1572,7 @@ SET ENABLE_SEQSCAN TO OFF;
|
||||
<listitem>
|
||||
<para>
|
||||
Controls which message levels are written to the server log.
|
||||
Valid values are <literal>DEBUG5</>, <literal>DEBUG4</>,
|
||||
Valid values are <literal>DEBUG5</>, <literal>DEBUG4</>,
|
||||
<literal>DEBUG3</>, <literal>DEBUG2</>, <literal>DEBUG1</>,
|
||||
<literal>INFO</>, <literal>NOTICE</>, <literal>WARNING</>,
|
||||
<literal>ERROR</>, <literal>LOG</>, <literal>FATAL</>, and
|
||||
@ -1591,9 +1591,9 @@ SET ENABLE_SEQSCAN TO OFF;
|
||||
<listitem>
|
||||
<para>
|
||||
Controls the amount of detail written in the server log for each
|
||||
message that is logged. Valid values are <literal>TERSE</>,
|
||||
<literal>DEFAULT</>, and <literal>VERBOSE</>, each adding more
|
||||
fields to displayed messages.
|
||||
message that is logged. Valid values are <literal>TERSE</>,
|
||||
<literal>DEFAULT</>, and <literal>VERBOSE</>, each adding more
|
||||
fields to displayed messages.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -1660,7 +1660,7 @@ SET ENABLE_SEQSCAN TO OFF;
|
||||
|
||||
<para>
|
||||
Here is a list of the various message severity levels used in
|
||||
these settings:
|
||||
these settings:
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term><literal>DEBUG[1-5]</literal></term>
|
||||
@ -2028,9 +2028,9 @@ SET ENABLE_SEQSCAN TO OFF;
|
||||
<listitem>
|
||||
<para>
|
||||
This parameter is normally true. When set false, it disables
|
||||
validation of the function body string in <command>CREATE FUNCTION</>.
|
||||
Disabling validation is occasionally useful to avoid problems such as
|
||||
forward references when restoring function definitions from a dump.
|
||||
validation of the function body string in <command>CREATE FUNCTION</>.
|
||||
Disabling validation is occasionally useful to avoid problems such as
|
||||
forward references when restoring function definitions from a dump.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -2100,15 +2100,15 @@ SET ENABLE_SEQSCAN TO OFF;
|
||||
<para>
|
||||
Sets the display format for date and time values, as well as
|
||||
the rules for interpreting ambiguous date input values.
|
||||
For historical reasons, this variable contains two independent
|
||||
components: the output format specification (<literal>ISO</>,
|
||||
<literal>Postgres</>, <literal>SQL</>, or <literal>German</>) and
|
||||
the date field order specification (<literal>DMY</>, <literal>MDY</>,
|
||||
or <literal>YMD</>). These can be set separately or together.
|
||||
The keywords <literal>Euro</> and <literal>European</> are synonyms
|
||||
for <literal>DMY</>; the keywords <literal>US</>, <literal>NonEuro</>,
|
||||
and <literal>NonEuropean</> are synonyms for <literal>MDY</>.
|
||||
See <xref linkend="datatype-datetime"> for more information. The
|
||||
For historical reasons, this variable contains two independent
|
||||
components: the output format specification (<literal>ISO</>,
|
||||
<literal>Postgres</>, <literal>SQL</>, or <literal>German</>) and
|
||||
the date field order specification (<literal>DMY</>, <literal>MDY</>,
|
||||
or <literal>YMD</>). These can be set separately or together.
|
||||
The keywords <literal>Euro</> and <literal>European</> are synonyms
|
||||
for <literal>DMY</>; the keywords <literal>US</>, <literal>NonEuro</>,
|
||||
and <literal>NonEuropean</> are synonyms for <literal>MDY</>.
|
||||
See <xref linkend="datatype-datetime"> for more information. The
|
||||
default is <literal>ISO, MDY</>.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -2390,13 +2390,13 @@ dynamic_library_path = '/usr/local/lib/postgresql:/home/my_project/lib:$libdir'
|
||||
<listitem>
|
||||
<para>
|
||||
When <literal>true</>, tables that are referenced by a query will be
|
||||
automatically added to the <literal>FROM</> clause if not already
|
||||
present. The default is <literal>true</> for compatibility with
|
||||
previous releases of <productname>PostgreSQL</>. However, this
|
||||
behavior is not SQL-standard, and many people dislike it because it
|
||||
can mask mistakes. Set to <literal>false</> for the SQL-standard
|
||||
behavior of rejecting references to tables that are not listed in
|
||||
<literal>FROM</>.
|
||||
automatically added to the <literal>FROM</> clause if not already
|
||||
present. The default is <literal>true</> for compatibility with
|
||||
previous releases of <productname>PostgreSQL</>. However, this
|
||||
behavior is not SQL-standard, and many people dislike it because it
|
||||
can mask mistakes. Set to <literal>false</> for the SQL-standard
|
||||
behavior of rejecting references to tables that are not listed in
|
||||
<literal>FROM</>.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -2521,10 +2521,10 @@ dynamic_library_path = '/usr/local/lib/postgresql:/home/my_project/lib:$libdir'
|
||||
<listitem>
|
||||
<para>
|
||||
If nonzero, a delay of this many seconds occurs just after a new
|
||||
server process is forked, before it conducts the authentication
|
||||
process. This is intended to give an opportunity to attach to the
|
||||
server process with a debugger to trace down misbehavior in
|
||||
authentication.
|
||||
server process is forked, before it conducts the authentication
|
||||
process. This is intended to give an opportunity to attach to the
|
||||
server process with a debugger to trace down misbehavior in
|
||||
authentication.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -2993,9 +2993,10 @@ options SEMMAP=256
|
||||
<literal>option</literal> singular.)
|
||||
</para>
|
||||
<para>
|
||||
You might also want to use the <command>sysctl</> setting to
|
||||
lock shared memory into RAM and prevent it from being paged out
|
||||
to swap, e.g. <literal>kern.ipc.shm_use_phys</>.
|
||||
You might also want to configure your kernel to lock shared
|
||||
memory into RAM and prevent it from being paged out to swap.
|
||||
Use the <command>sysctl</> setting
|
||||
<literal>kern.ipc.shm_use_phys</>.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -3059,65 +3060,6 @@ kernel.shmmax = 134217728
|
||||
<filename>/usr/src/linux/include/asm-<replaceable>xxx</>/shmpara
|
||||
m.h</> and <filename>/usr/src/linux/include/linux/sem.h</>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Linux kernel version 2.4.* has poor default memory overcommit
|
||||
behavior, which can result in the postmaster being killed by the
|
||||
kernel due to memory demands by another process if the system
|
||||
runs out of memory.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The symptom of this occurring is a kernel message looking like
|
||||
this (consult your system documentation and configuration on
|
||||
where to look for such a message):
|
||||
<programlisting>
|
||||
Out of Memory: Killed process 12345 (postmaster).
|
||||
</programlisting>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
To avoid this situation, run <productname>PostgreSQL</productname>
|
||||
on a machine where you
|
||||
can be sure that other processes will not run the machine out
|
||||
of memory. If your kernel supports strict and/or paranoid modes
|
||||
of overcommit handling, you can also relieve this problem by
|
||||
altering the system's default behaviour. This can be determined
|
||||
by examining the function <function>vm_enough_memory</>
|
||||
in the file <filename>mm/mmap.c</> in the kernel source.
|
||||
If this file reveals that strict and/or paranoid modes are
|
||||
supported by your kernel, turn one of these modes on by using
|
||||
<programlisting>
|
||||
sysctl -w vm.overcommit_memory=2
|
||||
</programlisting>
|
||||
for strict mode or
|
||||
<programlisting>
|
||||
sysctl -w vm.overcommit_memory=3
|
||||
</programlisting>
|
||||
for paranoid mode, or placing an equivalent entry in
|
||||
<filename>/etc/sysctl.conf</>.
|
||||
</para>
|
||||
|
||||
<note>
|
||||
<para>
|
||||
Warning: using these settings in a kernel which does not support
|
||||
these modes will almost certainly increase the danger of the
|
||||
kernel killing the postmaster, rather than reducing it.
|
||||
If in any doubt, consult a kernel expert or your kernel vendor.
|
||||
</para>
|
||||
</note>
|
||||
|
||||
<para>
|
||||
These modes are expected to be supported in all 2.6 and later
|
||||
kernels. Some vendor 2.4 kernels may also support these modes.
|
||||
However, it is known that some vendor documents suggest that
|
||||
they support them while examination of the kernel source reveals
|
||||
that they do not.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Note, you will need enough swap space to cover all your memory needs.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
@ -3319,6 +3261,71 @@ default:\
|
||||
</para>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Linux Memory Overcommit</title>
|
||||
|
||||
<para>
|
||||
Linux kernels of version 2.4.* have a poor default memory
|
||||
overcommit behavior, which can result in the PostgreSQL server
|
||||
(<filename>postmaster</filename> process) being killed by the
|
||||
kernel if the memory demands of another process cause the system
|
||||
to run out of memory.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
If this happens, you will see a kernel message looking like this
|
||||
(consult your system documentation and configuration on where to
|
||||
look for such a message):
|
||||
<programlisting>
|
||||
Out of Memory: Killed process 12345 (postmaster).
|
||||
</programlisting>
|
||||
And, of course, you will find that your database server has
|
||||
disappeared.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
To avoid this situation, run <productname>PostgreSQL</productname>
|
||||
on a machine where you can be sure that other processes will not
|
||||
run the machine out of memory. If your kernel supports the strict
|
||||
and/or paranoid modes of overcommit handling, you can also relieve
|
||||
this problem by altering the system's default behaviour. This can
|
||||
be determined by examining the function
|
||||
<function>vm_enough_memory</> in the file <filename>mm/mmap.c</>
|
||||
in the kernel source. If this file reveals that the strict and/or
|
||||
paranoid modes are supported by your kernel, turn one of these
|
||||
modes on by using
|
||||
<programlisting>
|
||||
sysctl -w vm.overcommit_memory=2
|
||||
</programlisting>
|
||||
for strict mode, or
|
||||
<programlisting>
|
||||
sysctl -w vm.overcommit_memory=3
|
||||
</programlisting>
|
||||
for paranoid mode, or placing an equivalent entry in
|
||||
<filename>/etc/sysctl.conf</>.
|
||||
</para>
|
||||
|
||||
<caution>
|
||||
<para>
|
||||
Using these settings in a kernel which does not support these
|
||||
modes will almost certainly increase the danger of the kernel
|
||||
killing the database server, rather than reducing it. If in any
|
||||
doubt, consult a kernel expert or your kernel vendor.
|
||||
</para>
|
||||
</caution>
|
||||
|
||||
<para>
|
||||
These modes are expected to be supported in all 2.6 and later
|
||||
kernels. Some vendor 2.4 kernels may also support these modes. It
|
||||
is, however, known that some vendor documents suggest that they
|
||||
support them while examination of the kernel source reveals that
|
||||
they do not.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Note, you will need enough swap space to cover all your memory needs.
|
||||
</para>
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/syntax.sgml,v 1.85 2003/11/01 01:56:29 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/syntax.sgml,v 1.86 2003/11/04 09:55:39 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="sql-syntax">
|
||||
@ -196,20 +196,16 @@ UPDATE "my_table" SET "a" = 5;
|
||||
unquoted names are always folded to lower case. For example, the
|
||||
identifiers <literal>FOO</literal>, <literal>foo</literal>, and
|
||||
<literal>"foo"</literal> are considered the same by
|
||||
<productname>PostgreSQL</productname>, but <literal>"Foo"</literal>
|
||||
and <literal>"FOO"</literal> are different from these three and
|
||||
each other.
|
||||
<footnote>
|
||||
<para>
|
||||
The folding of unquoted names to lower case in <productname>PostgreSQL</>
|
||||
is incompatible with the SQL standard, which says that unquoted
|
||||
names should be folded to upper case. Thus, <literal>foo</literal>
|
||||
should be equivalent to <literal>"FOO"</literal> not
|
||||
<literal>"foo"</literal> according to the standard. If you want to
|
||||
write portable applications you are advised to always quote a particular
|
||||
name or never quote it.
|
||||
</para>
|
||||
</footnote>
|
||||
<productname>PostgreSQL</productname>, but
|
||||
<literal>"Foo"</literal> and <literal>"FOO"</literal> are
|
||||
different from these three and each other. (The folding of
|
||||
unquoted names to lower case in <productname>PostgreSQL</> is
|
||||
incompatible with the SQL standard, which says that unquoted names
|
||||
should be folded to upper case. Thus, <literal>foo</literal>
|
||||
should be equivalent to <literal>"FOO"</literal> not
|
||||
<literal>"foo"</literal> according to the standard. If you want
|
||||
to write portable applications you are advised to always quote a
|
||||
particular name or never quote it.
|
||||
</para>
|
||||
</sect2>
|
||||
|
||||
@ -260,10 +256,12 @@ UPDATE "my_table" SET "a" = 5;
|
||||
form feed, <literal>\n</literal> is a newline,
|
||||
<literal>\r</literal> is a carriage return, <literal>\t</literal>
|
||||
is a tab, and <literal>\<replaceable>xxx</replaceable></literal>,
|
||||
where <replaceable>xxx</replaceable> is an octal number, is the
|
||||
character with the corresponding ASCII code. Any other character
|
||||
following a backslash is taken literally. Thus, to include a
|
||||
backslash in a string constant, type two backslashes.
|
||||
where <replaceable>xxx</replaceable> is an octal number, is a
|
||||
byte with the corresponding code. (It is your responsibility
|
||||
that the byte sequences you create are valid characters in the
|
||||
server character set encoding.) Any other character following a
|
||||
backslash is taken literally. Thus, to include a backslash in a
|
||||
string constant, type two backslashes.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@ -440,44 +438,8 @@ CAST ( '<replaceable>string</replaceable>' AS <replaceable>type</replaceable> )
|
||||
or <literal>CAST()</literal> to specify the type of an array constant.
|
||||
</para>
|
||||
</sect3>
|
||||
|
||||
<sect3>
|
||||
<title>Array constants</title>
|
||||
|
||||
<indexterm>
|
||||
<primary>array</primary>
|
||||
<secondary>constant</secondary>
|
||||
</indexterm>
|
||||
|
||||
<para>
|
||||
The general format of an array constant is the following:
|
||||
<synopsis>
|
||||
'{ <replaceable>val1</replaceable> <replaceable>delim</replaceable> <replaceable>val2</replaceable> <replaceable>delim</replaceable> ... }'
|
||||
</synopsis>
|
||||
where <replaceable>delim</replaceable> is the delimiter character
|
||||
for the type, as recorded in its <literal>pg_type</literal>
|
||||
entry. (For all built-in types, this is the comma character
|
||||
<quote><literal>,</literal></>.) Each <replaceable>val</replaceable> is either a constant
|
||||
of the array element type, or a subarray. An example of an
|
||||
array constant is
|
||||
<programlisting>
|
||||
'{{1,2,3},{4,5,6},{7,8,9}}'
|
||||
</programlisting>
|
||||
This constant is a two-dimensional, 3-by-3 array consisting of three
|
||||
subarrays of integers. For more information see <xref linkend="arrays">.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
(Array constants are actually only a special case of the generic
|
||||
type constants discussed in the previous section. The constant
|
||||
is initially treated as a string and passed to the array input
|
||||
conversion routine. An explicit type specification might be
|
||||
necessary.)
|
||||
</para>
|
||||
</sect3>
|
||||
</sect2>
|
||||
|
||||
|
||||
<sect2 id="sql-syntax-operators">
|
||||
<title>Operators</title>
|
||||
|
||||
@ -622,7 +584,7 @@ CAST ( '<replaceable>string</replaceable>' AS <replaceable>type</replaceable> )
|
||||
A comment is an arbitrary sequence of characters beginning with
|
||||
double dashes and extending to the end of the line, e.g.:
|
||||
<programlisting>
|
||||
-- This is a standard SQL92 comment
|
||||
-- This is a standard SQL comment
|
||||
</programlisting>
|
||||
</para>
|
||||
|
||||
@ -635,7 +597,7 @@ CAST ( '<replaceable>string</replaceable>' AS <replaceable>type</replaceable> )
|
||||
</programlisting>
|
||||
where the comment begins with <literal>/*</literal> and extends to
|
||||
the matching occurrence of <literal>*/</literal>. These block
|
||||
comments nest, as specified in SQL99 but unlike C, so that one can
|
||||
comments nest, as specified in the SQL standard but unlike C, so that one can
|
||||
comment out larger blocks of code that may contain existing block
|
||||
comments.
|
||||
</para>
|
||||
@ -1267,7 +1229,7 @@ CAST ( <replaceable>expression</replaceable> AS <replaceable>type</replaceable>
|
||||
there is no error; the scalar result is taken to be null.)
|
||||
The subquery can refer to variables from the surrounding query,
|
||||
which will act as constants during any one evaluation of the subquery.
|
||||
See also <xref linkend="functions-subquery">.
|
||||
See also <xref linkend="functions-subquery"> for other expressions involving subqueries.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@ -1289,7 +1251,7 @@ SELECT name, (SELECT max(pop) FROM cities WHERE cities.state = states.name)
|
||||
</indexterm>
|
||||
|
||||
<para>
|
||||
An <firstterm>array constructor</> is an expression that builds an
|
||||
An array constructor is an expression that builds an
|
||||
array value from values for its member elements. A simple array
|
||||
constructor
|
||||
consists of the key word <literal>ARRAY</literal>, a left square bracket
|
||||
@ -1337,11 +1299,11 @@ SELECT ARRAY[[1,2],[3,4]];
|
||||
an array of the proper kind, not only a sub-<literal>ARRAY</> construct.
|
||||
For example:
|
||||
<programlisting>
|
||||
create table arr(f1 int[], f2 int[]);
|
||||
CREATE TABLE
|
||||
insert into arr values (ARRAY[[1,2],[3,4]],ARRAY[[5,6],[7,8]]);
|
||||
INSERT 2635544 1
|
||||
select ARRAY[f1, f2, '{{9,10},{11,12}}'::int[]] from arr;
|
||||
CREATE TABLE arr(f1 int[], f2 int[]);
|
||||
|
||||
INSERT INTO arr VALUES (ARRAY[[1,2],[3,4]], ARRAY[[5,6],[7,8]]);
|
||||
|
||||
SELECT ARRAY[f1, f2, '{{9,10},{11,12}}'::int[]] FROM arr;
|
||||
array
|
||||
------------------------------------------------
|
||||
{{{1,2},{3,4}},{{5,6},{7,8}},{{9,10},{11,12}}}
|
||||
@ -1361,10 +1323,10 @@ SELECT ARRAY(SELECT oid FROM pg_proc WHERE proname LIKE 'bytea%');
|
||||
{2011,1954,1948,1952,1951,1244,1950,2005,1949,1953,2006,31}
|
||||
(1 row)
|
||||
</programlisting>
|
||||
The subquery must return a single column. The
|
||||
resulting one-dimensional array will have an element for each row in the
|
||||
subquery result, with an element type matching that of the subquery's
|
||||
output column.
|
||||
The subquery must return a single column. The resulting
|
||||
one-dimensional array will have an element for each row in the
|
||||
subquery result, with an element type matching that of the
|
||||
subquery's output column.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/typeconv.sgml,v 1.36 2003/11/01 01:56:29 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/typeconv.sgml,v 1.37 2003/11/04 09:55:39 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter Id="typeconv">
|
||||
@ -794,13 +794,14 @@ padding spaces.
|
||||
</indexterm>
|
||||
|
||||
<para>
|
||||
SQL <literal>UNION</> constructs must match up possibly dissimilar types to
|
||||
become a single result set. The resolution algorithm is applied separately
|
||||
to each output column of a union query. The <literal>INTERSECT</> and
|
||||
<literal>EXCEPT</> constructs resolve dissimilar types in the same way as
|
||||
<literal>UNION</>.
|
||||
A <literal>CASE</> construct uses the identical algorithm to match up its
|
||||
component expressions and select a result data type, as does <literal>ARRAY</>.
|
||||
SQL <literal>UNION</> constructs must match up possibly dissimilar
|
||||
types to become a single result set. The resolution algorithm is
|
||||
applied separately to each output column of a union query. The
|
||||
<literal>INTERSECT</> and <literal>EXCEPT</> constructs resolve
|
||||
dissimilar types in the same way as <literal>UNION</>. The
|
||||
<literal>CASE</> and <literal>ARRAY</> constructs use the identical
|
||||
algorithm to match up their component expressions and select a result
|
||||
data type.
|
||||
</para>
|
||||
|
||||
<procedure>
|
||||
|
Loading…
Reference in New Issue
Block a user