mirror of
https://github.com/postgres/postgres.git
synced 2025-06-13 07:41:39 +03:00
Merge documentation updates from 7.3 branch.
This commit is contained in:
@ -1,5 +1,5 @@
|
|||||||
<!--
|
<!--
|
||||||
$Header: /cvsroot/pgsql/doc/src/sgml/advanced.sgml,v 1.30 2002/10/24 17:48:54 petere Exp $
|
$Header: /cvsroot/pgsql/doc/src/sgml/advanced.sgml,v 1.31 2002/11/11 20:14:02 petere Exp $
|
||||||
-->
|
-->
|
||||||
|
|
||||||
<chapter id="tutorial-advanced">
|
<chapter id="tutorial-advanced">
|
||||||
@ -46,14 +46,14 @@ $Header: /cvsroot/pgsql/doc/src/sgml/advanced.sgml,v 1.30 2002/10/24 17:48:54 pe
|
|||||||
<firstterm>view</firstterm> over the query, which gives a name to
|
<firstterm>view</firstterm> over the query, which gives a name to
|
||||||
the query that you can refer to like an ordinary table.
|
the query that you can refer to like an ordinary table.
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
CREATE VIEW myview AS
|
CREATE VIEW myview AS
|
||||||
SELECT city, temp_lo, temp_hi, prcp, date, location
|
SELECT city, temp_lo, temp_hi, prcp, date, location
|
||||||
FROM weather, cities
|
FROM weather, cities
|
||||||
WHERE city = name;
|
WHERE city = name;
|
||||||
|
|
||||||
SELECT * FROM myview;
|
SELECT * FROM myview;
|
||||||
</programlisting>
|
</programlisting>
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
@ -101,7 +101,7 @@ SELECT * FROM myview;
|
|||||||
<para>
|
<para>
|
||||||
The new declaration of the tables would look like this:
|
The new declaration of the tables would look like this:
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
CREATE TABLE cities (
|
CREATE TABLE cities (
|
||||||
city varchar(80) primary key,
|
city varchar(80) primary key,
|
||||||
location point
|
location point
|
||||||
@ -114,23 +114,23 @@ CREATE TABLE weather (
|
|||||||
prcp real,
|
prcp real,
|
||||||
date date
|
date date
|
||||||
);
|
);
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
|
||||||
Now try inserting an invalid record:
|
Now try inserting an invalid record:
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
INSERT INTO weather VALUES ('Berkeley', 45, 53, 0.0, '1994-11-28');
|
INSERT INTO weather VALUES ('Berkeley', 45, 53, 0.0, '1994-11-28');
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
|
||||||
<screen>
|
<screen>
|
||||||
ERROR: <unnamed> referential integrity violation - key referenced from weather not found in cities
|
ERROR: <unnamed> referential integrity violation - key referenced from weather not found in cities
|
||||||
</screen>
|
</screen>
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
The behavior of foreign keys can be finely tuned to your
|
The behavior of foreign keys can be finely tuned to your
|
||||||
application. We will not go beyond this simple example in this
|
application. We will not go beyond this simple example in this
|
||||||
tutorial, but just refer you to the &cite-reference;
|
tutorial, but just refer you to the &cite-user;
|
||||||
for more information. Making correct use of
|
for more information. Making correct use of
|
||||||
foreign keys will definitely improve the quality of your database
|
foreign keys will definitely improve the quality of your database
|
||||||
applications, so you are strongly encouraged to learn about them.
|
applications, so you are strongly encouraged to learn about them.
|
||||||
@ -161,7 +161,7 @@ ERROR: <unnamed> referential integrity violation - key referenced from we
|
|||||||
to Bob's account. Simplifying outrageously, the SQL commands for this
|
to Bob's account. Simplifying outrageously, the SQL commands for this
|
||||||
might look like
|
might look like
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
UPDATE accounts SET balance = balance - 100.00
|
UPDATE accounts SET balance = balance - 100.00
|
||||||
WHERE name = 'Alice';
|
WHERE name = 'Alice';
|
||||||
UPDATE branches SET balance = balance - 100.00
|
UPDATE branches SET balance = balance - 100.00
|
||||||
@ -170,7 +170,7 @@ UPDATE accounts SET balance = balance + 100.00
|
|||||||
WHERE name = 'Bob';
|
WHERE name = 'Bob';
|
||||||
UPDATE branches SET balance = balance + 100.00
|
UPDATE branches SET balance = balance + 100.00
|
||||||
WHERE name = (SELECT branch_name FROM accounts WHERE name = 'Bob');
|
WHERE name = (SELECT branch_name FROM accounts WHERE name = 'Bob');
|
||||||
</programlisting>
|
</programlisting>
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
@ -222,13 +222,13 @@ UPDATE branches SET balance = balance + 100.00
|
|||||||
<command>BEGIN</> and <command>COMMIT</> commands. So our banking
|
<command>BEGIN</> and <command>COMMIT</> commands. So our banking
|
||||||
transaction would actually look like
|
transaction would actually look like
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
BEGIN;
|
BEGIN;
|
||||||
UPDATE accounts SET balance = balance - 100.00
|
UPDATE accounts SET balance = balance - 100.00
|
||||||
WHERE name = 'Alice';
|
WHERE name = 'Alice';
|
||||||
-- etc etc
|
-- etc etc
|
||||||
COMMIT;
|
COMMIT;
|
||||||
</programlisting>
|
</programlisting>
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
@ -278,7 +278,7 @@ COMMIT;
|
|||||||
implicitly when you list all cities. If you're really clever you
|
implicitly when you list all cities. If you're really clever you
|
||||||
might invent some scheme like this:
|
might invent some scheme like this:
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
CREATE TABLE capitals (
|
CREATE TABLE capitals (
|
||||||
name text,
|
name text,
|
||||||
population real,
|
population real,
|
||||||
@ -296,7 +296,7 @@ CREATE VIEW cities AS
|
|||||||
SELECT name, population, altitude FROM capitals
|
SELECT name, population, altitude FROM capitals
|
||||||
UNION
|
UNION
|
||||||
SELECT name, population, altitude FROM non_capitals;
|
SELECT name, population, altitude FROM non_capitals;
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
|
||||||
This works OK as far as querying goes, but it gets ugly when you
|
This works OK as far as querying goes, but it gets ugly when you
|
||||||
need to update several rows, to name one thing.
|
need to update several rows, to name one thing.
|
||||||
@ -305,7 +305,7 @@ CREATE VIEW cities AS
|
|||||||
<para>
|
<para>
|
||||||
A better solution is this:
|
A better solution is this:
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
CREATE TABLE cities (
|
CREATE TABLE cities (
|
||||||
name text,
|
name text,
|
||||||
population real,
|
population real,
|
||||||
@ -315,7 +315,7 @@ CREATE TABLE cities (
|
|||||||
CREATE TABLE capitals (
|
CREATE TABLE capitals (
|
||||||
state char(2)
|
state char(2)
|
||||||
) INHERITS (cities);
|
) INHERITS (cities);
|
||||||
</programlisting>
|
</programlisting>
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
@ -336,11 +336,11 @@ CREATE TABLE capitals (
|
|||||||
including state capitals, that are located at an altitude
|
including state capitals, that are located at an altitude
|
||||||
over 500 ft.:
|
over 500 ft.:
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
SELECT name, altitude
|
SELECT name, altitude
|
||||||
FROM cities
|
FROM cities
|
||||||
WHERE altitude > 500;
|
WHERE altitude > 500;
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
|
||||||
which returns:
|
which returns:
|
||||||
|
|
||||||
@ -359,11 +359,11 @@ SELECT name, altitude
|
|||||||
all the cities that are not state capitals and
|
all the cities that are not state capitals and
|
||||||
are situated at an altitude of 500 ft. or higher:
|
are situated at an altitude of 500 ft. or higher:
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
SELECT name, altitude
|
SELECT name, altitude
|
||||||
FROM ONLY cities
|
FROM ONLY cities
|
||||||
WHERE altitude > 500;
|
WHERE altitude > 500;
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
|
||||||
<screen>
|
<screen>
|
||||||
name | altitude
|
name | altitude
|
||||||
@ -380,7 +380,7 @@ SELECT name, altitude
|
|||||||
<classname>cities</classname> table, and not tables below
|
<classname>cities</classname> table, and not tables below
|
||||||
<classname>cities</classname> in the inheritance hierarchy. Many
|
<classname>cities</classname> in the inheritance hierarchy. Many
|
||||||
of the commands that we have already discussed --
|
of the commands that we have already discussed --
|
||||||
<command>SELECT</command>, <command>UPDATE</command> and
|
<command>SELECT</command>, <command>UPDATE</command>, and
|
||||||
<command>DELETE</command> -- support this <literal>ONLY</literal>
|
<command>DELETE</command> -- support this <literal>ONLY</literal>
|
||||||
notation.
|
notation.
|
||||||
</para>
|
</para>
|
||||||
|
@ -1,4 +1,4 @@
|
|||||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/array.sgml,v 1.23 2002/11/10 00:32:16 momjian Exp $ -->
|
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/array.sgml,v 1.24 2002/11/11 20:14:02 petere Exp $ -->
|
||||||
|
|
||||||
<sect1 id="arrays">
|
<sect1 id="arrays">
|
||||||
<title>Arrays</title>
|
<title>Arrays</title>
|
||||||
@ -21,7 +21,7 @@ CREATE TABLE sal_emp (
|
|||||||
</programlisting>
|
</programlisting>
|
||||||
As shown, an array data type is named by appending square brackets
|
As shown, an array data type is named by appending square brackets
|
||||||
(<literal>[]</>) to the data type name of the array elements.
|
(<literal>[]</>) to the data type name of the array elements.
|
||||||
The above query will create a table named
|
The above command will create a table named
|
||||||
<structname>sal_emp</structname> with columns including
|
<structname>sal_emp</structname> with columns including
|
||||||
a <type>text</type> string (<structfield>name</structfield>),
|
a <type>text</type> string (<structfield>name</structfield>),
|
||||||
a one-dimensional array of type
|
a one-dimensional array of type
|
||||||
@ -68,7 +68,7 @@ SELECT name FROM sal_emp WHERE pay_by_quarter[1] <> pay_by_quarter[2];
|
|||||||
|
|
||||||
The array subscript numbers are written within square brackets.
|
The array subscript numbers are written within square brackets.
|
||||||
By default <productname>PostgreSQL</productname> uses the
|
By default <productname>PostgreSQL</productname> uses the
|
||||||
<quote>one-based</quote> numbering convention for arrays, that is,
|
one-based numbering convention for arrays, that is,
|
||||||
an array of <replaceable>n</> elements starts with <literal>array[1]</literal> and
|
an array of <replaceable>n</> elements starts with <literal>array[1]</literal> and
|
||||||
ends with <literal>array[<replaceable>n</>]</literal>.
|
ends with <literal>array[<replaceable>n</>]</literal>.
|
||||||
</para>
|
</para>
|
||||||
@ -90,10 +90,9 @@ SELECT pay_by_quarter[3] FROM sal_emp;
|
|||||||
<para>
|
<para>
|
||||||
We can also access arbitrary rectangular slices of an array, or
|
We can also access arbitrary rectangular slices of an array, or
|
||||||
subarrays. An array slice is denoted by writing
|
subarrays. An array slice is denoted by writing
|
||||||
<literal><replaceable>lower subscript</replaceable> :
|
<literal><replaceable>lower-bound</replaceable>:<replaceable>upper-bound</replaceable></literal>
|
||||||
<replaceable>upper subscript</replaceable></literal> for one or more
|
for one or more array dimensions. This query retrieves the first
|
||||||
array dimensions. This query retrieves the first item on Bill's
|
item on Bill's schedule for the first two days of the week:
|
||||||
schedule for the first two days of the week:
|
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
SELECT schedule[1:2][1:1] FROM sal_emp WHERE name = 'Bill';
|
SELECT schedule[1:2][1:1] FROM sal_emp WHERE name = 'Bill';
|
||||||
@ -112,9 +111,10 @@ SELECT schedule[1:2][1] FROM sal_emp WHERE name = 'Bill';
|
|||||||
|
|
||||||
with the same result. An array subscripting operation is taken to
|
with the same result. An array subscripting operation is taken to
|
||||||
represent an array slice if any of the subscripts are written in the
|
represent an array slice if any of the subscripts are written in the
|
||||||
form <replaceable>lower</replaceable> <literal>:</literal>
|
form
|
||||||
<replaceable>upper</replaceable>. A lower bound of 1 is assumed for
|
<literal><replaceable>lower</replaceable>:<replaceable>upper</replaceable></literal>.
|
||||||
any subscript where only one value is specified.
|
A lower bound of 1 is assumed for any subscript where only one value
|
||||||
|
is specified.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
@ -310,7 +310,7 @@ SELECT * FROM sal_emp WHERE pay_by_quarter **= 10000;
|
|||||||
|
|
||||||
<tip>
|
<tip>
|
||||||
<para>
|
<para>
|
||||||
Remember that what you write in an SQL query will first be interpreted
|
Remember that what you write in an SQL command will first be interpreted
|
||||||
as a string literal, and then as an array. This doubles the number of
|
as a string literal, and then as an array. This doubles the number of
|
||||||
backslashes you need. For example, to insert a <type>text</> array
|
backslashes you need. For example, to insert a <type>text</> array
|
||||||
value containing a backslash and a double quote, you'd need to write
|
value containing a backslash and a double quote, you'd need to write
|
||||||
@ -323,7 +323,7 @@ INSERT ... VALUES ('{"\\\\","\\""}');
|
|||||||
become <literal>\</> and <literal>"</> respectively. (If we were working
|
become <literal>\</> and <literal>"</> respectively. (If we were working
|
||||||
with a data type whose input routine also treated backslashes specially,
|
with a data type whose input routine also treated backslashes specially,
|
||||||
<type>bytea</> for example, we might need as many as eight backslashes
|
<type>bytea</> for example, we might need as many as eight backslashes
|
||||||
in the query to get one backslash into the stored array element.)
|
in the command to get one backslash into the stored array element.)
|
||||||
</para>
|
</para>
|
||||||
</tip>
|
</tip>
|
||||||
|
|
||||||
|
@ -1,5 +1,5 @@
|
|||||||
<!--
|
<!--
|
||||||
$Header: /cvsroot/pgsql/doc/src/sgml/backup.sgml,v 2.23 2002/10/21 02:11:37 tgl Exp $
|
$Header: /cvsroot/pgsql/doc/src/sgml/backup.sgml,v 2.24 2002/11/11 20:14:02 petere Exp $
|
||||||
-->
|
-->
|
||||||
<chapter id="backup">
|
<chapter id="backup">
|
||||||
<title>Backup and Restore</title>
|
<title>Backup and Restore</title>
|
||||||
@ -64,7 +64,7 @@ pg_dump <replaceable class="parameter">dbname</replaceable> > <replaceable cl
|
|||||||
<para>
|
<para>
|
||||||
As any other <productname>PostgreSQL</> client application,
|
As any other <productname>PostgreSQL</> client application,
|
||||||
<application>pg_dump</> will by default connect with the database
|
<application>pg_dump</> will by default connect with the database
|
||||||
user name that is equal to the current Unix user name. To override
|
user name that is equal to the current operating system user name. To override
|
||||||
this, either specify the <option>-U</option> option or set the
|
this, either specify the <option>-U</option> option or set the
|
||||||
environment variable <envar>PGUSER</envar>. Remember that
|
environment variable <envar>PGUSER</envar>. Remember that
|
||||||
<application>pg_dump</> connections are subject to the normal
|
<application>pg_dump</> connections are subject to the normal
|
||||||
@ -104,9 +104,9 @@ psql <replaceable class="parameter">dbname</replaceable> < <replaceable class
|
|||||||
</synopsis>
|
</synopsis>
|
||||||
where <replaceable class="parameter">infile</replaceable> is what
|
where <replaceable class="parameter">infile</replaceable> is what
|
||||||
you used as <replaceable class="parameter">outfile</replaceable>
|
you used as <replaceable class="parameter">outfile</replaceable>
|
||||||
for the pg_dump command. The database <replaceable
|
for the <command>pg_dump</> command. The database <replaceable
|
||||||
class="parameter">dbname</replaceable> will not be created by this
|
class="parameter">dbname</replaceable> will not be created by this
|
||||||
command, you must create it yourself from template0 before executing
|
command, you must create it yourself from <literal>template0</> before executing
|
||||||
<application>psql</> (e.g., with <literal>createdb -T template0
|
<application>psql</> (e.g., with <literal>createdb -T template0
|
||||||
<replaceable class="parameter">dbname</></literal>).
|
<replaceable class="parameter">dbname</></literal>).
|
||||||
<application>psql</> supports similar options to <application>pg_dump</>
|
<application>psql</> supports similar options to <application>pg_dump</>
|
||||||
@ -129,21 +129,20 @@ psql <replaceable class="parameter">dbname</replaceable> < <replaceable class
|
|||||||
The ability of <application>pg_dump</> and <application>psql</> to
|
The ability of <application>pg_dump</> and <application>psql</> to
|
||||||
write to or read from pipes makes it possible to dump a database
|
write to or read from pipes makes it possible to dump a database
|
||||||
directly from one server to another, for example
|
directly from one server to another, for example
|
||||||
<informalexample>
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
pg_dump -h <replaceable>host1</> <replaceable>dbname</> | psql -h <replaceable>host2</> <replaceable>dbname</>
|
pg_dump -h <replaceable>host1</> <replaceable>dbname</> | psql -h <replaceable>host2</> <replaceable>dbname</>
|
||||||
</programlisting>
|
</programlisting>
|
||||||
</informalexample>
|
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
|
|
||||||
<important>
|
<important>
|
||||||
<para>
|
<para>
|
||||||
The dumps produced by pg_dump are relative to template0. This means
|
The dumps produced by <application>pg_dump</> are relative to
|
||||||
that any languages, procedures, etc. added to template1 will also be
|
<literal>template0</>. This means that any languages, procedures,
|
||||||
dumped by <application>pg_dump</>. As a result, when restoring, if
|
etc. added to <literal>template1</> will also be dumped by
|
||||||
you are using a customized template1, you must create the empty
|
<application>pg_dump</>. As a result, when restoring, if you are
|
||||||
database from template0, as in the example above.
|
using a customized <literal>template1</>, you must create the
|
||||||
|
empty database from <literal>template0</>, as in the example
|
||||||
|
above.
|
||||||
</para>
|
</para>
|
||||||
</important>
|
</important>
|
||||||
|
|
||||||
@ -222,20 +221,16 @@ cat <replaceable class="parameter">filename</replaceable>.gz | gunzip | psql <re
|
|||||||
acceptable in size to the underlying file system. For example, to
|
acceptable in size to the underlying file system. For example, to
|
||||||
make chunks of 1 megabyte:
|
make chunks of 1 megabyte:
|
||||||
|
|
||||||
<informalexample>
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
pg_dump <replaceable class="parameter">dbname</replaceable> | split -b 1m - <replaceable class="parameter">filename</replaceable>
|
pg_dump <replaceable class="parameter">dbname</replaceable> | split -b 1m - <replaceable class="parameter">filename</replaceable>
|
||||||
</programlisting>
|
</programlisting>
|
||||||
</informalexample>
|
|
||||||
|
|
||||||
Reload with
|
Reload with
|
||||||
|
|
||||||
<informalexample>
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
createdb <replaceable class="parameter">dbname</replaceable>
|
createdb <replaceable class="parameter">dbname</replaceable>
|
||||||
cat <replaceable class="parameter">filename</replaceable>* | psql <replaceable class="parameter">dbname</replaceable>
|
cat <replaceable class="parameter">filename</replaceable>* | psql <replaceable class="parameter">dbname</replaceable>
|
||||||
</programlisting>
|
</programlisting>
|
||||||
</informalexample>
|
|
||||||
</para>
|
</para>
|
||||||
</formalpara>
|
</formalpara>
|
||||||
|
|
||||||
@ -249,14 +244,11 @@ cat <replaceable class="parameter">filename</replaceable>* | psql <replaceable c
|
|||||||
restored selectively. The following command dumps a database using the
|
restored selectively. The following command dumps a database using the
|
||||||
custom dump format:
|
custom dump format:
|
||||||
|
|
||||||
<informalexample>
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
pg_dump -Fc <replaceable class="parameter">dbname</replaceable> > <replaceable class="parameter">filename</replaceable>
|
pg_dump -Fc <replaceable class="parameter">dbname</replaceable> > <replaceable class="parameter">filename</replaceable>
|
||||||
</programlisting>
|
</programlisting>
|
||||||
</informalexample>
|
|
||||||
|
|
||||||
See the <application>pg_dump</> and <application>pg_restore</> reference pages for details.
|
See the <application>pg_dump</> and <application>pg_restore</> reference pages for details.
|
||||||
|
|
||||||
</para>
|
</para>
|
||||||
</formalpara>
|
</formalpara>
|
||||||
|
|
||||||
@ -284,7 +276,7 @@ pg_dump -Fc <replaceable class="parameter">dbname</replaceable> > <replaceable c
|
|||||||
<para>
|
<para>
|
||||||
For reasons of backward compatibility, <application>pg_dump</> does
|
For reasons of backward compatibility, <application>pg_dump</> does
|
||||||
not dump large objects by default. To dump large objects you must use
|
not dump large objects by default. To dump large objects you must use
|
||||||
either the custom or the TAR output format, and use the -b option in
|
either the custom or the TAR output format, and use the <option>-b</> option in
|
||||||
<application>pg_dump</>. See the reference pages for details.
|
<application>pg_dump</>. See the reference pages for details.
|
||||||
The directory <filename>contrib/pg_dumplo</> of the
|
The directory <filename>contrib/pg_dumplo</> of the
|
||||||
<productname>PostgreSQL</> source tree also contains a program that can
|
<productname>PostgreSQL</> source tree also contains a program that can
|
||||||
@ -308,11 +300,10 @@ pg_dump -Fc <replaceable class="parameter">dbname</replaceable> > <replaceable c
|
|||||||
are located, but you have probably found them already if you are
|
are located, but you have probably found them already if you are
|
||||||
interested in this method. You can use whatever method you prefer
|
interested in this method. You can use whatever method you prefer
|
||||||
for doing usual file system backups, for example
|
for doing usual file system backups, for example
|
||||||
<informalexample>
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
tar -cf backup.tar /usr/local/pgsql/data
|
tar -cf backup.tar /usr/local/pgsql/data
|
||||||
</programlisting>
|
</programlisting>
|
||||||
</informalexample>
|
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
@ -390,11 +381,11 @@ tar -cf backup.tar /usr/local/pgsql/data
|
|||||||
The least downtime can be achieved by installing the new server in
|
The least downtime can be achieved by installing the new server in
|
||||||
a different directory and running both the old and the new servers
|
a different directory and running both the old and the new servers
|
||||||
in parallel, on different ports. Then you can use something like
|
in parallel, on different ports. Then you can use something like
|
||||||
<informalexample>
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
pg_dumpall -p 5432 | psql -d template1 -p 6543
|
pg_dumpall -p 5432 | psql -d template1 -p 6543
|
||||||
</programlisting>
|
</programlisting>
|
||||||
</informalexample>
|
|
||||||
to transfer your data, or use an intermediate file if you want.
|
to transfer your data, or use an intermediate file if you want.
|
||||||
Then you can shut down the old server and start the new server at
|
Then you can shut down the old server and start the new server at
|
||||||
the port the old one was running at. You should make sure that the
|
the port the old one was running at. You should make sure that the
|
||||||
@ -410,7 +401,7 @@ pg_dumpall -p 5432 | psql -d template1 -p 6543
|
|||||||
do the back up step before installing the new version, bring down
|
do the back up step before installing the new version, bring down
|
||||||
the server, move the old version out of the way, install the new
|
the server, move the old version out of the way, install the new
|
||||||
version, start the new server, restore the data. For example:
|
version, start the new server, restore the data. For example:
|
||||||
<informalexample>
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
pg_dumpall > backup
|
pg_dumpall > backup
|
||||||
pg_ctl stop
|
pg_ctl stop
|
||||||
@ -421,7 +412,7 @@ initdb -D /usr/local/pgsql/data
|
|||||||
postmaster -D /usr/local/pgsql/data
|
postmaster -D /usr/local/pgsql/data
|
||||||
psql template1 < backup
|
psql template1 < backup
|
||||||
</programlisting>
|
</programlisting>
|
||||||
</informalexample>
|
|
||||||
See <xref linkend="runtime"> about ways to start and stop the
|
See <xref linkend="runtime"> about ways to start and stop the
|
||||||
server and other details. The installation instructions will advise
|
server and other details. The installation instructions will advise
|
||||||
you of strategic places to perform these steps.
|
you of strategic places to perform these steps.
|
||||||
|
@ -1,5 +1,5 @@
|
|||||||
<!--
|
<!--
|
||||||
$Header: /cvsroot/pgsql/doc/src/sgml/client-auth.sgml,v 1.39 2002/09/21 18:32:52 petere Exp $
|
$Header: /cvsroot/pgsql/doc/src/sgml/client-auth.sgml,v 1.40 2002/11/11 20:14:02 petere Exp $
|
||||||
-->
|
-->
|
||||||
|
|
||||||
<chapter id="client-authentication">
|
<chapter id="client-authentication">
|
||||||
@ -62,7 +62,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/client-auth.sgml,v 1.39 2002/09/21 18:32:52
|
|||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
The general format of the <filename>pg_hba.conf</filename> file is of
|
The general format of the <filename>pg_hba.conf</filename> file is
|
||||||
a set of records, one per line. Blank lines are ignored, as is any
|
a set of records, one per line. Blank lines are ignored, as is any
|
||||||
text after the <quote>#</quote> comment character. A record is made
|
text after the <quote>#</quote> comment character. A record is made
|
||||||
up of a number of fields which are separated by spaces and/or tabs.
|
up of a number of fields which are separated by spaces and/or tabs.
|
||||||
@ -305,8 +305,9 @@ hostssl <replaceable>database</replaceable> <replaceable>user</replaceable> <
|
|||||||
<para>
|
<para>
|
||||||
If you use the map <literal>sameuser</literal>, the user
|
If you use the map <literal>sameuser</literal>, the user
|
||||||
names are assumed to be identical. If not, the map name is
|
names are assumed to be identical. If not, the map name is
|
||||||
looked up in the <literal>$PGDATA/pg_ident.conf</literal>
|
looked up in the file <filename>pg_ident.conf</filename>
|
||||||
file. The connection is accepted if that file contains an
|
in the same directory as <filename>pg_hba.conf</filename>.
|
||||||
|
The connection is accepted if that file contains an
|
||||||
entry for this map name with the ident-supplied user name
|
entry for this map name with the ident-supplied user name
|
||||||
and the requested <productname>PostgreSQL</productname> user
|
and the requested <productname>PostgreSQL</productname> user
|
||||||
name.
|
name.
|
||||||
@ -473,7 +474,7 @@ local db1,db2,@demodbs all md5
|
|||||||
<para>
|
<para>
|
||||||
When <literal>trust</> authentication is specified,
|
When <literal>trust</> authentication is specified,
|
||||||
<productname>PostgreSQL</productname> assumes that anyone who can
|
<productname>PostgreSQL</productname> assumes that anyone who can
|
||||||
connect to the postmaster is authorized to access the database as
|
connect to the server is authorized to access the database as
|
||||||
whatever database user he specifies (including the database superuser).
|
whatever database user he specifies (including the database superuser).
|
||||||
This method should only be used when there is adequate system-level
|
This method should only be used when there is adequate system-level
|
||||||
protection on connections to the postmaster port.
|
protection on connections to the postmaster port.
|
||||||
@ -504,7 +505,7 @@ local db1,db2,@demodbs all md5
|
|||||||
<para>
|
<para>
|
||||||
<literal>trust</> authentication is only suitable for TCP connections
|
<literal>trust</> authentication is only suitable for TCP connections
|
||||||
if you trust every user on every machine that is allowed to connect
|
if you trust every user on every machine that is allowed to connect
|
||||||
to the postmaster by the <filename>pg_hba.conf</> lines that specify
|
to the server by the <filename>pg_hba.conf</> lines that specify
|
||||||
<literal>trust</>. It is seldom reasonable to use <literal>trust</>
|
<literal>trust</>. It is seldom reasonable to use <literal>trust</>
|
||||||
for any TCP connections other than those from <systemitem>localhost</> (127.0.0.1).
|
for any TCP connections other than those from <systemitem>localhost</> (127.0.0.1).
|
||||||
</para>
|
</para>
|
||||||
@ -538,14 +539,14 @@ local db1,db2,@demodbs all md5
|
|||||||
|
|
||||||
<para>
|
<para>
|
||||||
<productname>PostgreSQL</productname> database passwords are
|
<productname>PostgreSQL</productname> database passwords are
|
||||||
separate from operating system user passwords. Ordinarily, the
|
separate from operating system user passwords. The password for
|
||||||
password for each database user is stored in the pg_shadow system
|
each database user is stored in the <literal>pg_shadow</> system
|
||||||
catalog table. Passwords can be managed with the query language
|
catalog table. Passwords can be managed with the query language
|
||||||
commands <command>CREATE USER</command> and <command>ALTER
|
commands <command>CREATE USER</command> and <command>ALTER
|
||||||
USER</command>, e.g., <userinput>CREATE USER foo WITH PASSWORD
|
USER</command>, e.g., <userinput>CREATE USER foo WITH PASSWORD
|
||||||
'secret';</userinput>. By default, that is, if no password has been
|
'secret';</userinput>. By default, that is, if no password has
|
||||||
set up, the stored password is <literal>NULL</literal> and password
|
been set up, the stored password is null and
|
||||||
authentication will always fail for that user.
|
password authentication will always fail for that user.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
@ -554,8 +555,8 @@ local db1,db2,@demodbs all md5
|
|||||||
file. The file should contain user names separated by commas or one
|
file. The file should contain user names separated by commas or one
|
||||||
user name per line, and be in the same directory as
|
user name per line, and be in the same directory as
|
||||||
<filename>pg_hba.conf</>. Mention the (base) name of the file
|
<filename>pg_hba.conf</>. Mention the (base) name of the file
|
||||||
preceded with <literal>@</>in the <literal>USER</> column. The
|
preceded with <literal>@</> in the user column. The
|
||||||
<literal>DATABASE</> column can similarly accept a list of values or
|
database column can similarly accept a list of values or
|
||||||
a file name. You can also specify group names by preceding the group
|
a file name. You can also specify group names by preceding the group
|
||||||
name with <literal>+</>.
|
name with <literal>+</>.
|
||||||
</para>
|
</para>
|
||||||
@ -715,7 +716,7 @@ local db1,db2,@demodbs all md5
|
|||||||
Unix-domain sockets (currently <systemitem
|
Unix-domain sockets (currently <systemitem
|
||||||
class="osname">Linux</>, <systemitem class="osname">FreeBSD</>,
|
class="osname">Linux</>, <systemitem class="osname">FreeBSD</>,
|
||||||
<systemitem class="osname">NetBSD</>, and <systemitem
|
<systemitem class="osname">NetBSD</>, and <systemitem
|
||||||
class="osname">BSD/OS</>, ident authentication can also be applied
|
class="osname">BSD/OS</>), ident authentication can also be applied
|
||||||
to local connections. In this case, no security risk is added by
|
to local connections. In this case, no security risk is added by
|
||||||
using ident authentication; indeed it is a preferable choice for
|
using ident authentication; indeed it is a preferable choice for
|
||||||
local connections on such systems.
|
local connections on such systems.
|
||||||
|
File diff suppressed because it is too large
Load Diff
@ -1,5 +1,5 @@
|
|||||||
<!--
|
<!--
|
||||||
$Header: /cvsroot/pgsql/doc/src/sgml/datetime.sgml,v 2.28 2002/08/04 06:15:45 thomas Exp $
|
$Header: /cvsroot/pgsql/doc/src/sgml/datetime.sgml,v 2.29 2002/11/11 20:14:02 petere Exp $
|
||||||
Date/time details
|
Date/time details
|
||||||
-->
|
-->
|
||||||
|
|
||||||
@ -8,7 +8,7 @@ Date/time details
|
|||||||
|
|
||||||
<para>
|
<para>
|
||||||
<productname>PostgreSQL</productname> uses an internal heuristic
|
<productname>PostgreSQL</productname> uses an internal heuristic
|
||||||
parser for all date/time support. Dates and times are input as
|
parser for all date/time input support. Dates and times are input as
|
||||||
strings, and are broken up into distinct fields with a preliminary
|
strings, and are broken up into distinct fields with a preliminary
|
||||||
determination of what kind of information may be in the
|
determination of what kind of information may be in the
|
||||||
field. Each field is interpreted and either assigned a numeric
|
field. Each field is interpreted and either assigned a numeric
|
||||||
@ -25,10 +25,203 @@ Date/time details
|
|||||||
</para>
|
</para>
|
||||||
|
|
||||||
<sect1>
|
<sect1>
|
||||||
<title>Date/Time Keywords</title>
|
<title>Date/Time Input Interpretation</title>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
<table tocentry="1">
|
The date/time types are all decoded using a common set of routines.
|
||||||
|
</para>
|
||||||
|
|
||||||
|
<procedure>
|
||||||
|
<title>Date/Time Input Interpretation</title>
|
||||||
|
|
||||||
|
<step>
|
||||||
|
<para>
|
||||||
|
Break the input string into tokens and categorize each token as
|
||||||
|
a string, time, time zone, or number.
|
||||||
|
</para>
|
||||||
|
|
||||||
|
<substeps>
|
||||||
|
<step>
|
||||||
|
<para>
|
||||||
|
If the numeric token contains a colon (<literal>:</>), this is
|
||||||
|
a time string. Include all subsequent digits and colons.
|
||||||
|
</para>
|
||||||
|
</step>
|
||||||
|
|
||||||
|
<step>
|
||||||
|
<para>
|
||||||
|
If the numeric token contains a dash (<literal>-</>), slash
|
||||||
|
(<literal>/</>), or two or more dots (<literal>.</>), this is
|
||||||
|
a date string which may have a text month.
|
||||||
|
</para>
|
||||||
|
</step>
|
||||||
|
|
||||||
|
<step>
|
||||||
|
<para>
|
||||||
|
If the token is numeric only, then it is either a single field
|
||||||
|
or an ISO 8601 concatenated date (e.g.,
|
||||||
|
<literal>19990113</literal> for January 13, 1999) or time
|
||||||
|
(e.g. <literal>141516</literal> for 14:15:16).
|
||||||
|
</para>
|
||||||
|
</step>
|
||||||
|
|
||||||
|
<step>
|
||||||
|
<para>
|
||||||
|
If the token starts with a plus (<literal>+</>) or minus
|
||||||
|
(<literal>-</>), then it is either a time zone or a special
|
||||||
|
field.
|
||||||
|
</para>
|
||||||
|
</step>
|
||||||
|
</substeps>
|
||||||
|
</step>
|
||||||
|
|
||||||
|
<step>
|
||||||
|
<para>
|
||||||
|
If the token is a text string, match up with possible strings.
|
||||||
|
</para>
|
||||||
|
|
||||||
|
<substeps>
|
||||||
|
<step>
|
||||||
|
<para>
|
||||||
|
Do a binary-search table lookup for the token
|
||||||
|
as either a special string (e.g., <literal>today</literal>),
|
||||||
|
day (e.g., <literal>Thursday</literal>),
|
||||||
|
month (e.g., <literal>January</literal>),
|
||||||
|
or noise word (e.g., <literal>at</literal>, <literal>on</literal>).
|
||||||
|
</para>
|
||||||
|
|
||||||
|
<para>
|
||||||
|
Set field values and bit mask for fields.
|
||||||
|
For example, set year, month, day for <literal>today</literal>,
|
||||||
|
and additionally hour, minute, second for <literal>now</literal>.
|
||||||
|
</para>
|
||||||
|
</step>
|
||||||
|
|
||||||
|
<step>
|
||||||
|
<para>
|
||||||
|
If not found, do a similar binary-search table lookup to match
|
||||||
|
the token with a time zone.
|
||||||
|
</para>
|
||||||
|
</step>
|
||||||
|
|
||||||
|
<step>
|
||||||
|
<para>
|
||||||
|
If not found, throw an error.
|
||||||
|
</para>
|
||||||
|
</step>
|
||||||
|
</substeps>
|
||||||
|
</step>
|
||||||
|
|
||||||
|
<step>
|
||||||
|
<para>
|
||||||
|
The token is a number or number field.
|
||||||
|
</para>
|
||||||
|
|
||||||
|
<substeps>
|
||||||
|
<step>
|
||||||
|
<para>
|
||||||
|
If there are more than 4 digits,
|
||||||
|
and if no other date fields have been previously read, then interpret
|
||||||
|
as a <quote>concatenated date</quote> (e.g., <literal>19990118</literal>). 8
|
||||||
|
and 6 digits are interpreted as year, month, and day, while 7
|
||||||
|
and 5 digits are interpreted as year, day of year, respectively.
|
||||||
|
</para>
|
||||||
|
</step>
|
||||||
|
|
||||||
|
<step>
|
||||||
|
<para>
|
||||||
|
If the token is three digits
|
||||||
|
and a year has already been decoded, then interpret as day of year.
|
||||||
|
</para>
|
||||||
|
</step>
|
||||||
|
|
||||||
|
<step>
|
||||||
|
<para>
|
||||||
|
If four or six digits and a year has already been read, then
|
||||||
|
interpret as a time.
|
||||||
|
</para>
|
||||||
|
</step>
|
||||||
|
|
||||||
|
<step>
|
||||||
|
<para>
|
||||||
|
If four or more digits, then interpret as a year.
|
||||||
|
</para>
|
||||||
|
</step>
|
||||||
|
|
||||||
|
<step>
|
||||||
|
<para>
|
||||||
|
If in European date mode, and if the day field has not yet been read,
|
||||||
|
and if the value is less than or equal to 31, then interpret as a day.
|
||||||
|
</para>
|
||||||
|
</step>
|
||||||
|
|
||||||
|
<step>
|
||||||
|
<para>
|
||||||
|
If the month field has not yet been read,
|
||||||
|
and if the value is less than or equal to 12, then interpret as a month.
|
||||||
|
</para>
|
||||||
|
</step>
|
||||||
|
|
||||||
|
<step>
|
||||||
|
<para>
|
||||||
|
If the day field has not yet been read,
|
||||||
|
and if the value is less than or equal to 31, then interpret as a day.
|
||||||
|
</para>
|
||||||
|
</step>
|
||||||
|
|
||||||
|
<step>
|
||||||
|
<para>
|
||||||
|
If two digits or four or more digits, then interpret as a year.
|
||||||
|
</para>
|
||||||
|
</step>
|
||||||
|
|
||||||
|
<step>
|
||||||
|
<para>
|
||||||
|
Otherwise, throw an error.
|
||||||
|
</para>
|
||||||
|
</step>
|
||||||
|
</substeps>
|
||||||
|
</step>
|
||||||
|
|
||||||
|
<step>
|
||||||
|
<para>
|
||||||
|
If BC has been specified, negate the year and add one for
|
||||||
|
internal storage. (There is no year zero in the Gregorian
|
||||||
|
calendar, so numerically <literal>1BC</literal> becomes year
|
||||||
|
zero.)
|
||||||
|
</para>
|
||||||
|
</step>
|
||||||
|
|
||||||
|
<step>
|
||||||
|
<para>
|
||||||
|
If BC was not specified, and if the year field was two digits in length, then
|
||||||
|
adjust the year to 4 digits. If the field was less than 70, then add 2000;
|
||||||
|
otherwise, add 1900.
|
||||||
|
|
||||||
|
<tip>
|
||||||
|
<para>
|
||||||
|
Gregorian years AD 1-99 may be entered by using 4 digits with leading
|
||||||
|
zeros (e.g., <literal>0099</> is AD 99). Previous versions of
|
||||||
|
<productname>PostgreSQL</productname> accepted years with three
|
||||||
|
digits and with single digits, but as of version 7.0 the rules have
|
||||||
|
been tightened up to reduce the possibility of ambiguity.
|
||||||
|
</para>
|
||||||
|
</tip>
|
||||||
|
</para>
|
||||||
|
</step>
|
||||||
|
</procedure>
|
||||||
|
</sect1>
|
||||||
|
|
||||||
|
|
||||||
|
<sect1>
|
||||||
|
<title>Date/Time Key Words</title>
|
||||||
|
|
||||||
|
<para>
|
||||||
|
<xref linkend="datetime-month-table"> shows the tokens that are
|
||||||
|
permissible as abbreviations for the names of the month.
|
||||||
|
</para>
|
||||||
|
|
||||||
|
<table id="datetime-month-table">
|
||||||
<title>Month Abbreviations</title>
|
<title>Month Abbreviations</title>
|
||||||
<tgroup cols="2">
|
<tgroup cols="2">
|
||||||
<thead>
|
<thead>
|
||||||
@ -88,13 +281,17 @@ Date/time details
|
|||||||
|
|
||||||
<note>
|
<note>
|
||||||
<para>
|
<para>
|
||||||
The month <literal>May</literal> has no explicit abbreviation, for obvious reasons.
|
The month May has no explicit abbreviation, for obvious reasons.
|
||||||
</para>
|
</para>
|
||||||
</note>
|
</note>
|
||||||
</para>
|
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
<table tocentry="1">
|
<xref linkend="datetime-dow-table"> shows the tokens that are
|
||||||
|
permissible as abbreviations for the names of the days of the
|
||||||
|
week.
|
||||||
|
</para>
|
||||||
|
|
||||||
|
<table id="datetime-dow-table">
|
||||||
<title>Day of the Week Abbreviations</title>
|
<title>Day of the Week Abbreviations</title>
|
||||||
<tgroup cols="2">
|
<tgroup cols="2">
|
||||||
<thead>
|
<thead>
|
||||||
@ -135,12 +332,14 @@ Date/time details
|
|||||||
</tbody>
|
</tbody>
|
||||||
</tgroup>
|
</tgroup>
|
||||||
</table>
|
</table>
|
||||||
</para>
|
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
<table tocentry="1">
|
<xref linkend="datetime-mod-table"> shows the tokens that serve
|
||||||
<title><productname>PostgreSQL</productname> Field Modifiers</title>
|
various modifier purposes.
|
||||||
<titleabbrev>Field Modifiers</titleabbrev>
|
</para>
|
||||||
|
|
||||||
|
<table id="datetime-mod-table">
|
||||||
|
<title>Date/Time Field Modifiers</title>
|
||||||
<tgroup cols="2">
|
<tgroup cols="2">
|
||||||
<thead>
|
<thead>
|
||||||
<row>
|
<row>
|
||||||
@ -151,7 +350,7 @@ Date/time details
|
|||||||
<tbody>
|
<tbody>
|
||||||
<row>
|
<row>
|
||||||
<entry><literal>ABSTIME</literal></entry>
|
<entry><literal>ABSTIME</literal></entry>
|
||||||
<entry>Keyword ignored</entry>
|
<entry>Key word ignored</entry>
|
||||||
</row>
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry><literal>AM</literal></entry>
|
<entry><literal>AM</literal></entry>
|
||||||
@ -159,7 +358,7 @@ Date/time details
|
|||||||
</row>
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry><literal>AT</literal></entry>
|
<entry><literal>AT</literal></entry>
|
||||||
<entry>Keyword ignored</entry>
|
<entry>Key word ignored</entry>
|
||||||
</row>
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry><literal>JULIAN</>, <literal>JD</>, <literal>J</></entry>
|
<entry><literal>JULIAN</>, <literal>JD</>, <literal>J</></entry>
|
||||||
@ -167,7 +366,7 @@ Date/time details
|
|||||||
</row>
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry><literal>ON</literal></entry>
|
<entry><literal>ON</literal></entry>
|
||||||
<entry>Keyword ignored</entry>
|
<entry>Key word ignored</entry>
|
||||||
</row>
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry><literal>PM</literal></entry>
|
<entry><literal>PM</literal></entry>
|
||||||
@ -180,44 +379,40 @@ Date/time details
|
|||||||
</tbody>
|
</tbody>
|
||||||
</tgroup>
|
</tgroup>
|
||||||
</table>
|
</table>
|
||||||
</para>
|
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
The keyword <literal>ABSTIME</literal> is ignored for historical
|
The key word <literal>ABSTIME</literal> is ignored for historical
|
||||||
reasons; in very old releases of
|
reasons; in very old releases of
|
||||||
<productname>PostgreSQL</productname> invalid <type>ABSTIME</type>
|
<productname>PostgreSQL</productname> invalid fields of type <type>abstime</type>
|
||||||
fields were emitted as <literal>Invalid Abstime</literal>. This is no
|
were emitted as <literal>Invalid Abstime</literal>. This is no
|
||||||
longer the case however and this keyword will likely be dropped in
|
longer the case however and this key word will likely be dropped in
|
||||||
a future release.
|
a future release.
|
||||||
</para>
|
</para>
|
||||||
</sect1>
|
|
||||||
|
|
||||||
<sect1 id="timezones">
|
<indexterm>
|
||||||
<title>Time Zones</title>
|
|
||||||
|
|
||||||
<indexterm zone="timezones">
|
|
||||||
<primary>time zones</primary>
|
<primary>time zones</primary>
|
||||||
</indexterm>
|
</indexterm>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
|
<xref linkend="datetime-timezone-table"> shows the time zone
|
||||||
|
abbreviations recognized by <productname>PostgreSQL</productname>.
|
||||||
<productname>PostgreSQL</productname> contains internal tabular
|
<productname>PostgreSQL</productname> contains internal tabular
|
||||||
information for time zone decoding, since there is no *nix standard
|
information for time zone decoding, since there is no standard
|
||||||
system interface to provide access to general, cross-timezone
|
operating system interface to provide access to general,
|
||||||
information. The underlying OS <emphasis>is</emphasis> used to
|
cross-time zone information. The underlying operating system
|
||||||
provide time zone information for <emphasis>output</emphasis>, however.
|
<emphasis>is</emphasis> used to provide time zone information for
|
||||||
|
<emphasis>output</emphasis>, however.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
The following table of time zones recognized by
|
The table is organized by time zone offset from <acronym>UTC</>,
|
||||||
<productname>PostgreSQL</productname> is organized by time
|
rather than alphabetically; this is intended to facilitate
|
||||||
zone offset from UTC, rather than alphabetically; this is intended
|
|
||||||
to facilitate
|
|
||||||
matching local usage with recognized abbreviations for cases where
|
matching local usage with recognized abbreviations for cases where
|
||||||
these might differ.
|
these might differ.
|
||||||
|
</para>
|
||||||
|
|
||||||
<table tocentry="1">
|
<table id="datetime-timezone-table">
|
||||||
<title><productname>PostgreSQL</productname> Recognized Time Zones</title>
|
<title>Time Zone Abbreviations</title>
|
||||||
<titleabbrev>Time Zones</titleabbrev>
|
|
||||||
<tgroup cols="3">
|
<tgroup cols="3">
|
||||||
<thead>
|
<thead>
|
||||||
<row>
|
<row>
|
||||||
@ -749,31 +944,29 @@ Date/time details
|
|||||||
</tbody>
|
</tbody>
|
||||||
</tgroup>
|
</tgroup>
|
||||||
</table>
|
</table>
|
||||||
</para>
|
|
||||||
|
|
||||||
<sect2>
|
<formalpara>
|
||||||
<title>Australian Time Zones</title>
|
<title>Australian Time Zones</title>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
Australian time zones and their naming variants
|
There are three naming conflicts between Australian time zone
|
||||||
account for fully one quarter of all time zones in the
|
names with time zones commonly used in North and South America:
|
||||||
<productname>PostgreSQL</productname> time zone lookup table.
|
<literal>ACST</literal>, <literal>CST</literal>, and
|
||||||
There are two naming conflicts with time zones commonly used
|
<literal>EST</literal>. If the run-time option
|
||||||
in the United States, <literal>CST</literal> and <literal>EST</literal>.
|
<varname>AUSTRALIAN_TIMEZONES</varname> is set to true then
|
||||||
|
<literal>ACST</literal>, <literal>CST</literal>,
|
||||||
|
<literal>EST</literal>, and <literal>SAT</literal> are interpreted
|
||||||
|
as Australian time zone names, as shown in <xref
|
||||||
|
linkend="datetime-oztz-table">. If it is false (which is the
|
||||||
|
default), then <literal>ACST</literal>, <literal>CST</literal>,
|
||||||
|
and <literal>EST</literal> are taken as American time zone names,
|
||||||
|
and <literal>SAT</literal> is interpreted as a noise word
|
||||||
|
indicating Saturday.
|
||||||
</para>
|
</para>
|
||||||
|
</formalpara>
|
||||||
|
|
||||||
<para>
|
<table id="datetime-oztz-table">
|
||||||
If the run-time option <literal>AUSTRALIAN_TIMEZONES</literal> is set
|
<title>Australian Time Zone Abbreviations</title>
|
||||||
then <literal>CST</literal>, <literal>EST</literal>, and
|
|
||||||
<literal>SAT</literal> will be
|
|
||||||
interpreted as Australian timezone names. Without this option,
|
|
||||||
<literal>CST</literal> and <literal>EST</literal> are taken as
|
|
||||||
American timezone names, while <literal>SAT</literal> is interpreted as a
|
|
||||||
noise word indicating <literal>Saturday</literal>.
|
|
||||||
|
|
||||||
<table tocentry="1">
|
|
||||||
<title><productname>PostgreSQL</productname> Australian Time Zones</title>
|
|
||||||
<titleabbrev>Australian Time Zones</titleabbrev>
|
|
||||||
<tgroup cols="3">
|
<tgroup cols="3">
|
||||||
<thead>
|
<thead>
|
||||||
<row>
|
<row>
|
||||||
@ -806,193 +999,7 @@ Date/time details
|
|||||||
</tbody>
|
</tbody>
|
||||||
</tgroup>
|
</tgroup>
|
||||||
</table>
|
</table>
|
||||||
</para>
|
|
||||||
</sect2>
|
|
||||||
|
|
||||||
<sect2>
|
|
||||||
<title>Date/Time Input Interpretation</title>
|
|
||||||
|
|
||||||
<para>
|
|
||||||
The date/time types are all decoded using a common set of routines.
|
|
||||||
</para>
|
|
||||||
|
|
||||||
<procedure>
|
|
||||||
<title>Date/Time Input Interpretation</title>
|
|
||||||
|
|
||||||
<step>
|
|
||||||
<para>
|
|
||||||
Break the input string into tokens and categorize each token as
|
|
||||||
a string, time, time zone, or number.
|
|
||||||
</para>
|
|
||||||
|
|
||||||
<substeps>
|
|
||||||
<step>
|
|
||||||
<para>
|
|
||||||
If the numeric token contains a colon (":"), this is a time
|
|
||||||
string. Include all subsequent digits and colons.
|
|
||||||
</para>
|
|
||||||
</step>
|
|
||||||
|
|
||||||
<step>
|
|
||||||
<para>
|
|
||||||
If the numeric token contains a dash ("-"), slash ("/"), or
|
|
||||||
two or more dots ("."),
|
|
||||||
this is a date string which may have a text month.
|
|
||||||
</para>
|
|
||||||
</step>
|
|
||||||
|
|
||||||
<step>
|
|
||||||
<para>
|
|
||||||
If the token is numeric only, then it is either a single field
|
|
||||||
or an ISO-8601 concatenated date
|
|
||||||
(e.g. <literal>19990113</literal> for January 13, 1999)
|
|
||||||
or time (e.g. 141516 for 14:15:16).
|
|
||||||
</para>
|
|
||||||
</step>
|
|
||||||
<step>
|
|
||||||
<para>
|
|
||||||
If the token starts with a plus ("+") or minus ("-"),
|
|
||||||
then it is either a time zone or a special field.
|
|
||||||
</para>
|
|
||||||
</step>
|
|
||||||
</substeps>
|
|
||||||
</step>
|
|
||||||
|
|
||||||
<step>
|
|
||||||
<para>
|
|
||||||
If the token is a text string, match up with possible strings.
|
|
||||||
</para>
|
|
||||||
|
|
||||||
<substeps>
|
|
||||||
<step>
|
|
||||||
<para>
|
|
||||||
Do a binary-search table lookup for the token
|
|
||||||
as either a special string (e.g. <literal>today</literal>),
|
|
||||||
day (e.g. <literal>Thursday</literal>),
|
|
||||||
month (e.g. <literal>January</literal>),
|
|
||||||
or noise word (e.g. <literal>at</literal>, <literal>on</literal>).
|
|
||||||
</para>
|
|
||||||
<para>
|
|
||||||
Set field values and bit mask for fields.
|
|
||||||
For example, set year, month, day for <literal>today</literal>,
|
|
||||||
and additionally hour, minute, second for <literal>now</literal>.
|
|
||||||
</para>
|
|
||||||
</step>
|
|
||||||
|
|
||||||
<step>
|
|
||||||
<para>
|
|
||||||
If not found, do a similar binary-search table lookup to match
|
|
||||||
the token with a time zone.
|
|
||||||
</para>
|
|
||||||
</step>
|
|
||||||
|
|
||||||
<step>
|
|
||||||
<para>
|
|
||||||
If not found, throw an error.
|
|
||||||
</para>
|
|
||||||
</step>
|
|
||||||
</substeps>
|
|
||||||
</step>
|
|
||||||
|
|
||||||
<step>
|
|
||||||
<para>
|
|
||||||
The token is a number or number field.
|
|
||||||
</para>
|
|
||||||
|
|
||||||
<substeps>
|
|
||||||
<step>
|
|
||||||
<para>
|
|
||||||
If there are more than 4 digits,
|
|
||||||
and if no other date fields have been previously read, then interpret
|
|
||||||
as a <quote>concatenated date</quote> (e.g. <literal>19990118</literal>). 8
|
|
||||||
and 6 digits are interpreted as year, month, and day, while 7
|
|
||||||
and 5 digits are interpreted as year, day of year, respectively.
|
|
||||||
</para>
|
|
||||||
</step>
|
|
||||||
|
|
||||||
<step>
|
|
||||||
<para>
|
|
||||||
If the token is three digits
|
|
||||||
and a year has already been decoded, then interpret as day of year.
|
|
||||||
</para>
|
|
||||||
</step>
|
|
||||||
|
|
||||||
<step>
|
|
||||||
<para>
|
|
||||||
If four or six digits and a year has already been read, then
|
|
||||||
interpret as a time.
|
|
||||||
</para>
|
|
||||||
</step>
|
|
||||||
|
|
||||||
<step>
|
|
||||||
<para>
|
|
||||||
If four or more digits, then interpret as a year.
|
|
||||||
</para>
|
|
||||||
</step>
|
|
||||||
|
|
||||||
<step>
|
|
||||||
<para>
|
|
||||||
If in European date mode, and if the day field has not yet been read,
|
|
||||||
and if the value is less than or equal to 31, then interpret as a day.
|
|
||||||
</para>
|
|
||||||
</step>
|
|
||||||
|
|
||||||
<step>
|
|
||||||
<para>
|
|
||||||
If the month field has not yet been read,
|
|
||||||
and if the value is less than or equal to 12, then interpret as a month.
|
|
||||||
</para>
|
|
||||||
</step>
|
|
||||||
|
|
||||||
<step>
|
|
||||||
<para>
|
|
||||||
If the day field has not yet been read,
|
|
||||||
and if the value is less than or equal to 31, then interpret as a day.
|
|
||||||
</para>
|
|
||||||
</step>
|
|
||||||
|
|
||||||
<step>
|
|
||||||
<para>
|
|
||||||
If two digits or four or more digits, then interpret as a year.
|
|
||||||
</para>
|
|
||||||
</step>
|
|
||||||
|
|
||||||
<step>
|
|
||||||
<para>
|
|
||||||
Otherwise, throw an error.
|
|
||||||
</para>
|
|
||||||
</step>
|
|
||||||
</substeps>
|
|
||||||
</step>
|
|
||||||
|
|
||||||
<step>
|
|
||||||
<para>
|
|
||||||
If BC has been specified, negate the year and add one for
|
|
||||||
internal storage
|
|
||||||
(there is no year zero in the Gregorian calendar, so numerically
|
|
||||||
<literal>1BC</literal> becomes year zero).
|
|
||||||
</para>
|
|
||||||
</step>
|
|
||||||
|
|
||||||
<step>
|
|
||||||
<para>
|
|
||||||
If BC was not specified, and if the year field was two digits in length, then
|
|
||||||
adjust the year to 4 digits. If the field was less than 70, then add 2000;
|
|
||||||
otherwise, add 1900.
|
|
||||||
|
|
||||||
<tip>
|
|
||||||
<para>
|
|
||||||
Gregorian years 1-99AD may be entered by using 4 digits with leading
|
|
||||||
zeros (e.g. 0099 is 99AD). Previous versions of
|
|
||||||
<productname>PostgreSQL</productname> accepted years with three
|
|
||||||
digits and with single digits, but as of version 7.0 the rules have
|
|
||||||
been tightened up to reduce the possibility of ambiguity.
|
|
||||||
</para>
|
|
||||||
</tip>
|
|
||||||
</para>
|
|
||||||
</step>
|
|
||||||
</procedure>
|
|
||||||
</sect2>
|
|
||||||
</sect1>
|
</sect1>
|
||||||
|
|
||||||
<sect1 id="units-history">
|
<sect1 id="units-history">
|
||||||
@ -1016,21 +1023,19 @@ Date/time details
|
|||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
<quote>Julian Day</quote> is different from <quote>Julian Date</quote>.
|
The <quote>Julian Day</quote> is different from the <quote>Julian
|
||||||
|
Date</quote>. The Julian date refers to the Julian calendar, which
|
||||||
The Julian calendar was introduced by Julius Caesar in 45 BC. It was
|
was introduced by Julius Caesar in 45 BC. It was in common use
|
||||||
in common use until the 1582, when countries started changing to the
|
until the 1582, when countries started changing to the Gregorian
|
||||||
Gregorian calendar.
|
calendar. In the Julian calendar, the tropical year is
|
||||||
|
approximated as 365 1/4 days = 365.25 days. This gives an error of
|
||||||
In the Julian calendar, the tropical year is approximated as 365 1/4
|
about 1 day in 128 years.
|
||||||
days = 365.25 days. This gives an error of about 1 day in
|
|
||||||
128 years.
|
|
||||||
The accumulating calendar error prompted Pope Gregory XIII
|
|
||||||
to reform the calendar in accordance with instructions
|
|
||||||
from the Council of Trent.
|
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
|
The accumulating calendar error prompted
|
||||||
|
Pope Gregory XIII to reform the calendar in accordance with
|
||||||
|
instructions from the Council of Trent.
|
||||||
In the Gregorian calendar, the tropical year is approximated as
|
In the Gregorian calendar, the tropical year is approximated as
|
||||||
365 + 97 / 400 days = 365.2425 days. Thus it takes approximately 3300
|
365 + 97 / 400 days = 365.2425 days. Thus it takes approximately 3300
|
||||||
years for the tropical year to shift one day with respect to the
|
years for the tropical year to shift one day with respect to the
|
||||||
@ -1066,35 +1071,34 @@ Date/time details
|
|||||||
This was observed in Italy, Poland, Portugal, and Spain. Other Catholic
|
This was observed in Italy, Poland, Portugal, and Spain. Other Catholic
|
||||||
countries followed shortly after, but Protestant countries were
|
countries followed shortly after, but Protestant countries were
|
||||||
reluctant to change, and the Greek orthodox countries didn't change
|
reluctant to change, and the Greek orthodox countries didn't change
|
||||||
until the start of this century.
|
until the start of the 20th century.
|
||||||
|
|
||||||
The reform was observed by Great Britain and Dominions (including what is
|
The reform was observed by Great Britain and Dominions (including what is
|
||||||
now the USA) in 1752.
|
now the USA) in 1752.
|
||||||
Thus 2 Sep 1752 was followed by 14 Sep 1752.
|
Thus 2 September 1752 was followed by 14 September 1752.
|
||||||
|
|
||||||
This is why Unix systems have <application>cal</application>
|
This is why Unix systems have the <command>cal</command> program
|
||||||
produce the following:
|
produce the following:
|
||||||
|
|
||||||
<programlisting>
|
<screen>
|
||||||
% cal 9 1752
|
$ <userinput>cal 9 1752</userinput>
|
||||||
September 1752
|
September 1752
|
||||||
S M Tu W Th F S
|
S M Tu W Th F S
|
||||||
1 2 14 15 16
|
1 2 14 15 16
|
||||||
17 18 19 20 21 22 23
|
17 18 19 20 21 22 23
|
||||||
24 25 26 27 28 29 30
|
24 25 26 27 28 29 30
|
||||||
</programlisting>
|
</screen>
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<note>
|
<note>
|
||||||
<para>
|
<para>
|
||||||
SQL92 states that
|
The SQL standard states that <quote>Within the definition of a
|
||||||
<quote>Within the definition of a <quote>datetime literal</quote>,
|
<quote>datetime literal</quote>, the <quote>datetime
|
||||||
the <quote>datetime value</quote>s are constrained by the
|
value</quote>s are constrained by the natural rules for dates and
|
||||||
natural rules for dates and times
|
times according to the Gregorian calendar</quote>. Dates between
|
||||||
according to the Gregorian calendar</quote>.
|
1752-09-03 and 1752-09-13, although eliminated in some countries
|
||||||
Dates between 1752-09-03 and 1752-09-13, although eliminated in
|
by Papal fiat, conform to <quote>natural rules</quote> and are
|
||||||
some countries by Papal fiat, conform to
|
hence valid dates.
|
||||||
<quote>natural rules</quote> and are hence valid dates.
|
|
||||||
</para>
|
</para>
|
||||||
</note>
|
</note>
|
||||||
|
|
||||||
@ -1108,7 +1112,7 @@ Date/time details
|
|||||||
calendar in 2637 BC.
|
calendar in 2637 BC.
|
||||||
|
|
||||||
The People's Republic of China uses the Gregorian calendar
|
The People's Republic of China uses the Gregorian calendar
|
||||||
for civil purposes. Chinese calendar is used for determining
|
for civil purposes. The Chinese calendar is used for determining
|
||||||
festivals.
|
festivals.
|
||||||
</para>
|
</para>
|
||||||
</sect1>
|
</sect1>
|
||||||
|
@ -1,4 +1,4 @@
|
|||||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/ddl.sgml,v 1.8 2002/10/24 21:10:58 tgl Exp $ -->
|
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/ddl.sgml,v 1.9 2002/11/11 20:14:02 petere Exp $ -->
|
||||||
|
|
||||||
<chapter id="ddl">
|
<chapter id="ddl">
|
||||||
<title>Data Definition</title>
|
<title>Data Definition</title>
|
||||||
@ -222,7 +222,7 @@ DROP TABLE products;
|
|||||||
<para>
|
<para>
|
||||||
The identity (transaction ID) of the deleting transaction, or
|
The identity (transaction ID) of the deleting transaction, or
|
||||||
zero for an undeleted tuple. It is possible for this field to
|
zero for an undeleted tuple. It is possible for this field to
|
||||||
be nonzero in a visible tuple: that usually indicates that the
|
be nonzero in a visible tuple: That usually indicates that the
|
||||||
deleting transaction hasn't committed yet, or that an attempted
|
deleting transaction hasn't committed yet, or that an attempted
|
||||||
deletion was rolled back.
|
deletion was rolled back.
|
||||||
</para>
|
</para>
|
||||||
@ -353,7 +353,7 @@ CREATE TABLE products (
|
|||||||
price numeric <emphasis>CONSTRAINT positive_price</emphasis> CHECK (price > 0)
|
price numeric <emphasis>CONSTRAINT positive_price</emphasis> CHECK (price > 0)
|
||||||
);
|
);
|
||||||
</programlisting>
|
</programlisting>
|
||||||
To specify a named constraint, use the key word
|
So, to specify a named constraint, use the key word
|
||||||
<literal>CONSTRAINT</literal> followed by an identifier followed
|
<literal>CONSTRAINT</literal> followed by an identifier followed
|
||||||
by the constraint definition.
|
by the constraint definition.
|
||||||
</para>
|
</para>
|
||||||
@ -382,7 +382,7 @@ CREATE TABLE products (
|
|||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
We say that the first two are column constraints, whereas the
|
We say that the first two constraints are column constraints, whereas the
|
||||||
third one is a table constraint because it is written separately
|
third one is a table constraint because it is written separately
|
||||||
from the column definitions. Column constraints can also be
|
from the column definitions. Column constraints can also be
|
||||||
written as table constraints, while the reverse is not necessarily
|
written as table constraints, while the reverse is not necessarily
|
||||||
@ -931,7 +931,7 @@ WHERE c.altitude > 500 and c.tableoid = p.oid;
|
|||||||
<para>
|
<para>
|
||||||
In previous versions of <productname>PostgreSQL</productname>, the
|
In previous versions of <productname>PostgreSQL</productname>, the
|
||||||
default was not to get access to child tables. This was found to
|
default was not to get access to child tables. This was found to
|
||||||
be error prone and is also in violation of SQL99. Under the old
|
be error prone and is also in violation of the SQL standard. Under the old
|
||||||
syntax, to get the sub-tables you append <literal>*</literal> to the table name.
|
syntax, to get the sub-tables you append <literal>*</literal> to the table name.
|
||||||
For example
|
For example
|
||||||
<programlisting>
|
<programlisting>
|
||||||
@ -1609,7 +1609,7 @@ REVOKE CREATE ON public FROM PUBLIC;
|
|||||||
standard. Therefore, many users consider qualified names to
|
standard. Therefore, many users consider qualified names to
|
||||||
really consist of
|
really consist of
|
||||||
<literal><replaceable>username</>.<replaceable>tablename</></literal>.
|
<literal><replaceable>username</>.<replaceable>tablename</></literal>.
|
||||||
This is also supported by PostgreSQL if you create a per-user
|
This is how PostgreSQL will effectively behave if you create a per-user
|
||||||
schema for every user.
|
schema for every user.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
@ -1693,8 +1693,8 @@ DROP TABLE products CASCADE;
|
|||||||
</screen>
|
</screen>
|
||||||
and all the dependent objects will be removed. In this case, it
|
and all the dependent objects will be removed. In this case, it
|
||||||
doesn't remove the orders table, it only removes the foreign key
|
doesn't remove the orders table, it only removes the foreign key
|
||||||
constraint. (If you want to check what DROP ... CASCADE will do,
|
constraint. (If you want to check what <literal>DROP ... CASCADE</> will do,
|
||||||
run DROP without CASCADE and read the NOTICEs.)
|
run <command>DROP</> without <literal>CASCADE</> and read the <literal>NOTICE</> messages.)
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
|
@ -1,5 +1,5 @@
|
|||||||
<!--
|
<!--
|
||||||
$Header: /cvsroot/pgsql/doc/src/sgml/diskusage.sgml,v 1.6 2002/10/16 22:06:33 petere Exp $
|
$Header: /cvsroot/pgsql/doc/src/sgml/diskusage.sgml,v 1.7 2002/11/11 20:14:02 petere Exp $
|
||||||
-->
|
-->
|
||||||
|
|
||||||
<chapter id="diskusage">
|
<chapter id="diskusage">
|
||||||
@ -32,7 +32,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/diskusage.sgml,v 1.6 2002/10/16 22:06:33 pe
|
|||||||
<para>
|
<para>
|
||||||
You can monitor disk space from three places: from
|
You can monitor disk space from three places: from
|
||||||
<application>psql</> using <command>VACUUM</> information, from
|
<application>psql</> using <command>VACUUM</> information, from
|
||||||
<application>psql</> using <application>contrib/dbsize</>, and from
|
<application>psql</> using <filename>contrib/dbsize</>, and from
|
||||||
the command line using <application>contrib/oid2name</>. Using
|
the command line using <application>contrib/oid2name</>. Using
|
||||||
<application>psql</> on a recently vacuumed (or analyzed) database,
|
<application>psql</> on a recently vacuumed (or analyzed) database,
|
||||||
you can issue queries to see the disk usage of any table:
|
you can issue queries to see the disk usage of any table:
|
||||||
@ -94,13 +94,14 @@ play-# ORDER BY relpages DESC;
|
|||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
<application>dbsize</> loads functions into your database that allow
|
<filename>contrib/dbsize</> loads functions into your database that allow
|
||||||
you to find the size of a table or database from inside
|
you to find the size of a table or database from inside
|
||||||
<application>psql</> without the need for <command>VACUUM/ANALYZE.</>
|
<application>psql</> without the need for <command>VACUUM/ANALYZE.</>
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
You can also use <application>oid2name</> to show disk usage. See
|
You can also use <filename>contrib/oid2name</> to show disk usage. See
|
||||||
<filename>README.oid2name</> for examples. It includes a script
|
<filename>README.oid2name</> for examples. It includes a script that
|
||||||
shows disk usage for each database.
|
shows disk usage for each database.
|
||||||
</para>
|
</para>
|
||||||
</sect1>
|
</sect1>
|
||||||
|
@ -1,4 +1,4 @@
|
|||||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/dml.sgml,v 1.2 2002/10/20 05:05:46 tgl Exp $ -->
|
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/dml.sgml,v 1.3 2002/11/11 20:14:02 petere Exp $ -->
|
||||||
|
|
||||||
<chapter id="dml">
|
<chapter id="dml">
|
||||||
<title>Data Manipulation</title>
|
<title>Data Manipulation</title>
|
||||||
@ -23,10 +23,10 @@
|
|||||||
<para>
|
<para>
|
||||||
When a table is created, it contains no data. The first thing to
|
When a table is created, it contains no data. The first thing to
|
||||||
do before a database can be of much use is to insert data. Data is
|
do before a database can be of much use is to insert data. Data is
|
||||||
inserted one row at a time. This does not mean that there are no
|
conceptually inserted one row at a time. Of course you can also
|
||||||
means to <quote>bulk load</quote> many rows efficiently. But there
|
insert more than one row, but there is no way to insert less than
|
||||||
is no way to insert less than one row at a time. Even if you know
|
one row at a time. Even if you know only some column values, a
|
||||||
only some column values, a complete row must be created.
|
complete row must be created.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
@ -84,6 +84,15 @@ INSERT INTO products (product_no, name, price) VALUES (1, 'Cheese', DEFAULT);
|
|||||||
INSERT INTO products DEFAULT VALUES;
|
INSERT INTO products DEFAULT VALUES;
|
||||||
</programlisting>
|
</programlisting>
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
|
<tip>
|
||||||
|
<para>
|
||||||
|
To do <quote>bulk loads</quote>, that is, inserting a lot of data,
|
||||||
|
take a look at the <command>COPY</command> command (see
|
||||||
|
&cite-reference;). It is not as flexible as the
|
||||||
|
<command>INSERT</command> command, but more efficient.
|
||||||
|
</para>
|
||||||
|
</tip>
|
||||||
</sect1>
|
</sect1>
|
||||||
|
|
||||||
<sect1 id="dml-update">
|
<sect1 id="dml-update">
|
||||||
|
File diff suppressed because it is too large
Load Diff
@ -1,4 +1,4 @@
|
|||||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/indices.sgml,v 1.37 2002/09/21 18:32:53 petere Exp $ -->
|
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/indices.sgml,v 1.38 2002/11/11 20:14:03 petere Exp $ -->
|
||||||
|
|
||||||
<chapter id="indexes">
|
<chapter id="indexes">
|
||||||
<title id="indexes-title">Indexes</title>
|
<title id="indexes-title">Indexes</title>
|
||||||
@ -432,172 +432,6 @@ SELECT am.amname AS acc_method,
|
|||||||
</sect1>
|
</sect1>
|
||||||
|
|
||||||
|
|
||||||
<sect1 id="keys">
|
|
||||||
<title id="keys-title">Keys</title>
|
|
||||||
|
|
||||||
<para>
|
|
||||||
<note>
|
|
||||||
<title>Author</title>
|
|
||||||
<para>
|
|
||||||
Written by Herouth Maoz (<email>herouth@oumail.openu.ac.il</email>).
|
|
||||||
This originally appeared on the User's Mailing List on 1998-03-02
|
|
||||||
in response to the question:
|
|
||||||
"What is the difference between PRIMARY KEY and UNIQUE constraints?".
|
|
||||||
</para>
|
|
||||||
</note>
|
|
||||||
</para>
|
|
||||||
|
|
||||||
<para>
|
|
||||||
<literallayout>
|
|
||||||
Subject: Re: [QUESTIONS] PRIMARY KEY | UNIQUE
|
|
||||||
|
|
||||||
What's the difference between:
|
|
||||||
|
|
||||||
PRIMARY KEY(fields,...) and
|
|
||||||
UNIQUE (fields,...)
|
|
||||||
|
|
||||||
- Is this an alias?
|
|
||||||
- If PRIMARY KEY is already unique, then why
|
|
||||||
is there another kind of key named UNIQUE?
|
|
||||||
</literallayout>
|
|
||||||
</para>
|
|
||||||
|
|
||||||
<para>
|
|
||||||
A primary key is the field(s) used to identify a specific row. For example,
|
|
||||||
Social Security numbers identifying a person.
|
|
||||||
</para>
|
|
||||||
|
|
||||||
<para>
|
|
||||||
A simply UNIQUE combination of fields has nothing to do with identifying
|
|
||||||
the row. It's simply an integrity constraint. For example, I have
|
|
||||||
collections of links. Each collection is identified by a unique number,
|
|
||||||
which is the primary key. This key is used in relations.
|
|
||||||
</para>
|
|
||||||
|
|
||||||
<para>
|
|
||||||
However, my application requires that each collection will also have a
|
|
||||||
unique name. Why? So that a human being who wants to modify a collection
|
|
||||||
will be able to identify it. It's much harder to know, if you have two
|
|
||||||
collections named <quote>Life Science</quote>, the one tagged 24433 is the one you
|
|
||||||
need, and the one tagged 29882 is not.
|
|
||||||
</para>
|
|
||||||
|
|
||||||
<para>
|
|
||||||
So, the user selects the collection by its name. We therefore make sure,
|
|
||||||
within the database, that names are unique. However, no other table in the
|
|
||||||
database relates to the collections table by the collection Name. That
|
|
||||||
would be very inefficient.
|
|
||||||
</para>
|
|
||||||
|
|
||||||
<para>
|
|
||||||
Moreover, despite being unique, the collection name does not actually
|
|
||||||
define the collection! For example, if somebody decided to change the name
|
|
||||||
of the collection from <quote>Life Science</quote> to <quote>Biology</quote>, it will still be the
|
|
||||||
same collection, only with a different name. As long as the name is unique,
|
|
||||||
that's OK.
|
|
||||||
</para>
|
|
||||||
|
|
||||||
<para>
|
|
||||||
So:
|
|
||||||
|
|
||||||
<itemizedlist>
|
|
||||||
<listitem>
|
|
||||||
<para>
|
|
||||||
Primary key:
|
|
||||||
<itemizedlist spacing="compact" mark="bullet">
|
|
||||||
<listitem>
|
|
||||||
<para>
|
|
||||||
Is used for identifying the row and relating to it.
|
|
||||||
</para>
|
|
||||||
</listitem>
|
|
||||||
<listitem>
|
|
||||||
<para>
|
|
||||||
Is impossible (or hard) to update.
|
|
||||||
</para>
|
|
||||||
</listitem>
|
|
||||||
<listitem>
|
|
||||||
<para>
|
|
||||||
Should not allow null values.
|
|
||||||
</para>
|
|
||||||
</listitem>
|
|
||||||
</itemizedlist>
|
|
||||||
</para>
|
|
||||||
</listitem>
|
|
||||||
|
|
||||||
<listitem>
|
|
||||||
<para>
|
|
||||||
Unique field(s):
|
|
||||||
<itemizedlist spacing="compact" mark="bullet">
|
|
||||||
<listitem>
|
|
||||||
<para>
|
|
||||||
Are used as an alternative access to the row.
|
|
||||||
</para>
|
|
||||||
</listitem>
|
|
||||||
<listitem>
|
|
||||||
<para>
|
|
||||||
Are updatable, so long as they are kept unique.
|
|
||||||
</para>
|
|
||||||
</listitem>
|
|
||||||
<listitem>
|
|
||||||
<para>
|
|
||||||
Null values are acceptable.
|
|
||||||
</para>
|
|
||||||
</listitem>
|
|
||||||
</itemizedlist>
|
|
||||||
</para>
|
|
||||||
</listitem>
|
|
||||||
</itemizedlist>
|
|
||||||
</para>
|
|
||||||
|
|
||||||
<para>
|
|
||||||
As for why no non-unique keys are defined explicitly in standard
|
|
||||||
<acronym>SQL</acronym> syntax? Well, you
|
|
||||||
must understand that indexes are implementation-dependent.
|
|
||||||
<acronym>SQL</acronym> does not
|
|
||||||
define the implementation, merely the relations between data in the
|
|
||||||
database. <productname>PostgreSQL</productname> does allow
|
|
||||||
non-unique indexes, but indexes
|
|
||||||
used to enforce <acronym>SQL</acronym> keys are always unique.
|
|
||||||
</para>
|
|
||||||
|
|
||||||
<para>
|
|
||||||
Thus, you may query a table by any combination of its columns, despite the
|
|
||||||
fact that you don't have an index on these columns. The indexes are merely
|
|
||||||
an implementation aid that each <acronym>RDBMS</acronym> offers
|
|
||||||
you, in order to cause
|
|
||||||
commonly used queries to be done more efficiently.
|
|
||||||
Some <acronym>RDBMS</acronym> may give you
|
|
||||||
additional measures, such as keeping a key stored in main memory. They will
|
|
||||||
have a special command, for example
|
|
||||||
<synopsis>
|
|
||||||
CREATE MEMSTORE ON <replaceable>table</replaceable> COLUMNS <replaceable>cols</replaceable>
|
|
||||||
</synopsis>
|
|
||||||
(This is not an existing command, just an example.)
|
|
||||||
</para>
|
|
||||||
|
|
||||||
<para>
|
|
||||||
In fact, when you create a primary key or a unique combination of fields,
|
|
||||||
nowhere in the <acronym>SQL</acronym> specification does it say
|
|
||||||
that an index is created, nor that
|
|
||||||
the retrieval of data by the key is going to be more efficient than a
|
|
||||||
sequential scan!
|
|
||||||
</para>
|
|
||||||
|
|
||||||
<para>
|
|
||||||
So, if you want to use a combination of fields that is not unique as a
|
|
||||||
secondary key, you really don't have to specify anything - just start
|
|
||||||
retrieving by that combination! However, if you want to make the retrieval
|
|
||||||
efficient, you'll have to resort to the means your
|
|
||||||
<acronym>RDBMS</acronym> provider gives you
|
|
||||||
- be it an index, my imaginary <literal>MEMSTORE</literal> command, or an intelligent
|
|
||||||
<acronym>RDBMS</acronym>
|
|
||||||
that creates indexes without your knowledge based on the fact that you have
|
|
||||||
sent it many queries based on a specific combination of keys... (It learns
|
|
||||||
from experience).
|
|
||||||
</para>
|
|
||||||
</sect1>
|
|
||||||
|
|
||||||
|
|
||||||
<sect1 id="indexes-partial">
|
<sect1 id="indexes-partial">
|
||||||
<title>Partial Indexes</title>
|
<title>Partial Indexes</title>
|
||||||
|
|
||||||
@ -876,8 +710,8 @@ CREATE UNIQUE INDEX tests_success_constraint ON tests (subject, target)
|
|||||||
<para>
|
<para>
|
||||||
When indexes are not used, it can be useful for testing to force
|
When indexes are not used, it can be useful for testing to force
|
||||||
their use. There are run-time parameters that can turn off
|
their use. There are run-time parameters that can turn off
|
||||||
various plan types (described in the <citetitle>Administrator's
|
various plan types (described in the &cite-admin;).
|
||||||
Guide</citetitle>). For instance, turning off sequential scans
|
For instance, turning off sequential scans
|
||||||
(<varname>enable_seqscan</>) and nested-loop joins
|
(<varname>enable_seqscan</>) and nested-loop joins
|
||||||
(<varname>enable_nestloop</>), which are the most basic plans,
|
(<varname>enable_nestloop</>), which are the most basic plans,
|
||||||
will force the system to use a different plan. If the system
|
will force the system to use a different plan. If the system
|
||||||
@ -906,8 +740,8 @@ CREATE UNIQUE INDEX tests_success_constraint ON tests (subject, target)
|
|||||||
again, two possibilities. The total cost is computed from the
|
again, two possibilities. The total cost is computed from the
|
||||||
per-row costs of each plan node times the selectivity estimate of
|
per-row costs of each plan node times the selectivity estimate of
|
||||||
the plan node. The costs of the plan nodes can be tuned with
|
the plan node. The costs of the plan nodes can be tuned with
|
||||||
run-time parameters (described in the <citetitle>Administrator's
|
run-time parameters (described in the &cite-admin;).
|
||||||
Guide</citetitle>). An inaccurate selectivity estimate is due to
|
An inaccurate selectivity estimate is due to
|
||||||
insufficient statistics. It may be possible to help this by
|
insufficient statistics. It may be possible to help this by
|
||||||
tuning the statistics-gathering parameters (see <command>ALTER
|
tuning the statistics-gathering parameters (see <command>ALTER
|
||||||
TABLE</command> reference).
|
TABLE</command> reference).
|
||||||
|
@ -6,14 +6,6 @@
|
|||||||
<secondary>on Windows</secondary>
|
<secondary>on Windows</secondary>
|
||||||
</indexterm>
|
</indexterm>
|
||||||
|
|
||||||
<abstract>
|
|
||||||
<para>
|
|
||||||
Build, installation, and use instructions for
|
|
||||||
<productname>PostgreSQL</productname> client libraries on
|
|
||||||
<productname>Windows</productname>
|
|
||||||
</para>
|
|
||||||
</abstract>
|
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
Although <productname>PostgreSQL</productname> is written for
|
Although <productname>PostgreSQL</productname> is written for
|
||||||
Unix-like operating systems, the C client library
|
Unix-like operating systems, the C client library
|
||||||
|
@ -1,4 +1,4 @@
|
|||||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/installation.sgml,v 1.110 2002/11/05 19:01:07 momjian Exp $ -->
|
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/installation.sgml,v 1.111 2002/11/11 20:14:03 petere Exp $ -->
|
||||||
|
|
||||||
<chapter id="installation">
|
<chapter id="installation">
|
||||||
<title><![%standalone-include[<productname>PostgreSQL</>]]>
|
<title><![%standalone-include[<productname>PostgreSQL</>]]>
|
||||||
@ -8,6 +8,13 @@
|
|||||||
<primary>installation</primary>
|
<primary>installation</primary>
|
||||||
</indexterm>
|
</indexterm>
|
||||||
|
|
||||||
|
<para>
|
||||||
|
This <![%standalone-include;[document.]]>
|
||||||
|
<![%standalone-ignore;[chapter.]]> describes the installation of
|
||||||
|
<productname>PostgreSQL</productname> from the source code
|
||||||
|
distribution.
|
||||||
|
</para>
|
||||||
|
|
||||||
<sect1 id="install-short">
|
<sect1 id="install-short">
|
||||||
<title>Short Version</title>
|
<title>Short Version</title>
|
||||||
|
|
||||||
@ -131,27 +138,30 @@ su - postgres
|
|||||||
<para>
|
<para>
|
||||||
To build the server programming language PL/Perl you need a full
|
To build the server programming language PL/Perl you need a full
|
||||||
Perl installation, including the <filename>libperl</filename>
|
Perl installation, including the <filename>libperl</filename>
|
||||||
library and the header files. Since PL/Perl is a shared
|
library and the header files. Since PL/Perl will be a shared
|
||||||
library, the <indexterm><primary>libperl</primary></indexterm>
|
library, the <indexterm><primary>libperl</primary></indexterm>
|
||||||
<filename>libperl</filename> library must be a shared library
|
<filename>libperl</filename> library must be a shared library
|
||||||
also on most platforms. At the time of this writing, this is
|
also on most platforms. This appears to be the default in
|
||||||
almost never the case in prebuilt Perl packages.
|
recent Perl versions, but it was not in earlier versions, and in
|
||||||
|
general it is the choice of whomever installed Perl at your
|
||||||
|
site.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
If this difficulty arises in your situation, a message like this
|
If you don't have the shared library but you need one, a message
|
||||||
will appear during the build to point out this fact:
|
like this will appear during the build to point out this fact:
|
||||||
<screen>
|
<screen>
|
||||||
*** Cannot build PL/Perl because libperl is not a shared library.
|
*** Cannot build PL/Perl because libperl is not a shared library.
|
||||||
*** You might have to rebuild your Perl installation. Refer to
|
*** You might have to rebuild your Perl installation. Refer to
|
||||||
*** the documentation for details.
|
*** the documentation for details.
|
||||||
</screen>
|
</screen>
|
||||||
(If you don't follow the on-screen output you will merely notice
|
(If you don't follow the on-screen output you will merely notice
|
||||||
the the PL/Perl library object will not be installed.) If you
|
that the PL/Perl library object, <filename>plperl.so</filename>
|
||||||
see this, you will have to re-build and install
|
or similar, will not be installed.) If you see this, you will
|
||||||
<productname>Perl</productname> manually to be able to build
|
have to rebuild and install <productname>Perl</productname>
|
||||||
PL/Perl. During the configuration process for
|
manually to be able to build PL/Perl. During the configuration
|
||||||
<productname>Perl</productname>, request a shared library.
|
process for <productname>Perl</productname>, request a shared
|
||||||
|
library.
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
@ -160,17 +170,18 @@ su - postgres
|
|||||||
To build the Python interface module or the PL/Python server
|
To build the Python interface module or the PL/Python server
|
||||||
programming language, you need a Python installation, including
|
programming language, you need a Python installation, including
|
||||||
the header files.
|
the header files.
|
||||||
</para>
|
Since PL/Python will be a shared library, the
|
||||||
|
|
||||||
<para>
|
|
||||||
Since PL/Python is a shared library, the
|
|
||||||
<indexterm><primary>libpython</primary></indexterm>
|
<indexterm><primary>libpython</primary></indexterm>
|
||||||
<filename>libpython</filename> library must be a shared library
|
<filename>libpython</filename> library must be a shared library
|
||||||
also on most platforms. This is not the case in a default
|
also on most platforms. This is not the case in a default
|
||||||
Python installation. If after building and installing you have
|
Python installation.
|
||||||
a file called <filename>plpython.so</filename> (possibly a
|
</para>
|
||||||
different extension), then everything went well. Otherwise you
|
|
||||||
should have seen a notice like this flying by:
|
<para>
|
||||||
|
If after building and installing you have a file called
|
||||||
|
<filename>plpython.so</filename> (possibly a different
|
||||||
|
extension), then everything went well. Otherwise you should
|
||||||
|
have seen a notice like this flying by:
|
||||||
<screen>
|
<screen>
|
||||||
*** Cannot build PL/Python because libpython is not a shared library.
|
*** Cannot build PL/Python because libpython is not a shared library.
|
||||||
*** You might have to rebuild your Python installation. Refer to
|
*** You might have to rebuild your Python installation. Refer to
|
||||||
@ -282,7 +293,7 @@ JAVACMD=$JAVA_HOME/bin/java
|
|||||||
<primary>yacc</primary>
|
<primary>yacc</primary>
|
||||||
</indexterm>
|
</indexterm>
|
||||||
|
|
||||||
<acronym>GNU</> <application>Flex</> and <application>Bison</>
|
<application>Flex</> and <application>Bison</>
|
||||||
are needed to build a CVS checkout or if you changed the actual
|
are needed to build a CVS checkout or if you changed the actual
|
||||||
scanner and parser definition files. If you need them, be sure
|
scanner and parser definition files. If you need them, be sure
|
||||||
to get <application>Flex</> 2.5.4 or later and
|
to get <application>Flex</> 2.5.4 or later and
|
||||||
@ -373,7 +384,7 @@ JAVACMD=$JAVA_HOME/bin/java
|
|||||||
<primary>pg_dumpall</primary>
|
<primary>pg_dumpall</primary>
|
||||||
</indexterm>
|
</indexterm>
|
||||||
|
|
||||||
To dump your database installation, type:
|
To back up your database installation, type:
|
||||||
<screen>
|
<screen>
|
||||||
<userinput>pg_dumpall > <replaceable>outputfile</></userinput>
|
<userinput>pg_dumpall > <replaceable>outputfile</></userinput>
|
||||||
</screen>
|
</screen>
|
||||||
@ -391,9 +402,16 @@ JAVACMD=$JAVA_HOME/bin/java
|
|||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
Make sure that you use the <command>pg_dumpall</> command
|
To make the backup, you can use the <command>pg_dumpall</command>
|
||||||
from the version you are currently running. &version;'s
|
command from the version you are currently running. For best
|
||||||
<command>pg_dumpall</> should not be used on older databases.
|
results, however, try to use the <command>pg_dumpall</command>
|
||||||
|
command from PostgreSQL &version;, since this version contains
|
||||||
|
bug fixes and improvements over older versions. While this
|
||||||
|
advice might seem idiosyncratic since you haven't installed the
|
||||||
|
new version yet, it is advisable to follow it if you plan to
|
||||||
|
install the new version in parallel with the old version. In
|
||||||
|
that case you can complete the installation normally and transfer
|
||||||
|
the data later. This will also decrease the downtime.
|
||||||
</para>
|
</para>
|
||||||
</step>
|
</step>
|
||||||
|
|
||||||
@ -453,12 +471,10 @@ JAVACMD=$JAVA_HOME/bin/java
|
|||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
You can also install the new version in parallel with the old one
|
These topics are discussed at length in <![%standalone-include[the
|
||||||
to decrease the downtime. These topics are discussed at length in
|
<citetitle>Administrator's Guide</>,]]> <![%standalone-ignore[<xref
|
||||||
<![%standalone-include[the <citetitle>Administrator's Guide</>,]]>
|
linkend="migration">,]]> which you are encouraged to read in any
|
||||||
<![%standalone-ignore[<xref linkend="migration">,]]>
|
case.
|
||||||
which you are encouraged
|
|
||||||
to read in any case.
|
|
||||||
</para>
|
</para>
|
||||||
</sect1>
|
</sect1>
|
||||||
|
|
||||||
@ -751,10 +767,6 @@ JAVACMD=$JAVA_HOME/bin/java
|
|||||||
server-side language. You need to have root access to be able
|
server-side language. You need to have root access to be able
|
||||||
to install the Python module at its default place
|
to install the Python module at its default place
|
||||||
(<filename>/usr/lib/python<replaceable>x</>.<replaceable>y</></>).
|
(<filename>/usr/lib/python<replaceable>x</>.<replaceable>y</></>).
|
||||||
To be able to use this option, you must have Python installed
|
|
||||||
and your system needs to support shared libraries. If you
|
|
||||||
instead want to build a new complete interpreter binary, you
|
|
||||||
will have to do it manually.
|
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
@ -763,7 +775,7 @@ JAVACMD=$JAVA_HOME/bin/java
|
|||||||
<term><option>--with-tcl</option></term>
|
<term><option>--with-tcl</option></term>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
Builds components that require Tcl/Tk, which are
|
Build components that require Tcl/Tk, which are
|
||||||
<application>libpgtcl</>, <application>pgtclsh</>,
|
<application>libpgtcl</>, <application>pgtclsh</>,
|
||||||
<application>pgtksh</application>,
|
<application>pgtksh</application>,
|
||||||
and <application>PL/Tcl</>. But see below about
|
and <application>PL/Tcl</>. But see below about
|
||||||
@ -1106,7 +1118,7 @@ All of PostgreSQL is successfully made. Ready to install.
|
|||||||
</procedure>
|
</procedure>
|
||||||
|
|
||||||
<formalpara>
|
<formalpara>
|
||||||
<title>Uninstall:</title>
|
<title>Uninstallation:</title>
|
||||||
<para>
|
<para>
|
||||||
To undo the installation use the command <command>gmake
|
To undo the installation use the command <command>gmake
|
||||||
uninstall</>. However, this will not remove any created directories.
|
uninstall</>. However, this will not remove any created directories.
|
||||||
@ -1192,7 +1204,7 @@ setenv LD_LIBRARY_PATH /usr/local/pgsql/lib
|
|||||||
|
|
||||||
<para>
|
<para>
|
||||||
On <systemitem class="osname">Cygwin</systemitem>, put the library
|
On <systemitem class="osname">Cygwin</systemitem>, put the library
|
||||||
directory on the <envar>PATH</envar> or move the
|
directory in the <envar>PATH</envar> or move the
|
||||||
<filename>.dll</filename> files into the <filename>bin/</filename>
|
<filename>.dll</filename> files into the <filename>bin/</filename>
|
||||||
directory.
|
directory.
|
||||||
</para>
|
</para>
|
||||||
@ -1735,7 +1747,7 @@ gunzip -c user.ps.gz \
|
|||||||
<entry>7.3</entry>
|
<entry>7.3</entry>
|
||||||
<entry>2002-11-01,
|
<entry>2002-11-01,
|
||||||
7.1.3 Larry Rosenman (<email>ler@lerctr.org</email>),
|
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>)
|
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>see also <filename>doc/FAQ_SCO</filename></entry>
|
||||||
</row>
|
</row>
|
||||||
<row>
|
<row>
|
||||||
|
@ -1,4 +1,4 @@
|
|||||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/keywords.sgml,v 2.7 2002/11/02 18:41:21 tgl Exp $ -->
|
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/keywords.sgml,v 2.8 2002/11/11 20:14:03 petere Exp $ -->
|
||||||
|
|
||||||
<appendix id="sql-keywords-appendix">
|
<appendix id="sql-keywords-appendix">
|
||||||
<title><acronym>SQL</acronym> Key Words</title>
|
<title><acronym>SQL</acronym> Key Words</title>
|
||||||
@ -232,13 +232,13 @@
|
|||||||
</row>
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry><token>ASSERTION</token></entry>
|
<entry><token>ASSERTION</token></entry>
|
||||||
<entry></entry>
|
<entry>non-reserved</entry>
|
||||||
<entry>reserved</entry>
|
<entry>reserved</entry>
|
||||||
<entry>reserved</entry>
|
<entry>reserved</entry>
|
||||||
</row>
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry><token>ASSIGNMENT</token></entry>
|
<entry><token>ASSIGNMENT</token></entry>
|
||||||
<entry></entry>
|
<entry>non-reserved</entry>
|
||||||
<entry>non-reserved</entry>
|
<entry>non-reserved</entry>
|
||||||
<entry></entry>
|
<entry></entry>
|
||||||
</row>
|
</row>
|
||||||
@ -262,7 +262,7 @@
|
|||||||
</row>
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry><token>AUTHORIZATION</token></entry>
|
<entry><token>AUTHORIZATION</token></entry>
|
||||||
<entry>non-reserved</entry>
|
<entry>reserved (can be function)</entry>
|
||||||
<entry>reserved</entry>
|
<entry>reserved</entry>
|
||||||
<entry>reserved</entry>
|
<entry>reserved</entry>
|
||||||
</row>
|
</row>
|
||||||
@ -296,6 +296,12 @@
|
|||||||
<entry>non-reserved</entry>
|
<entry>non-reserved</entry>
|
||||||
<entry>reserved</entry>
|
<entry>reserved</entry>
|
||||||
</row>
|
</row>
|
||||||
|
<row>
|
||||||
|
<entry><token>BIGINT</token></entry>
|
||||||
|
<entry>non-reserved (cannot be function or type)</entry>
|
||||||
|
<entry></entry>
|
||||||
|
<entry></entry>
|
||||||
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry><token>BINARY</token></entry>
|
<entry><token>BINARY</token></entry>
|
||||||
<entry>reserved (can be function)</entry>
|
<entry>reserved (can be function)</entry>
|
||||||
@ -328,7 +334,7 @@
|
|||||||
</row>
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry><token>BOOLEAN</token></entry>
|
<entry><token>BOOLEAN</token></entry>
|
||||||
<entry></entry>
|
<entry>non-reserved (cannot be function or type)</entry>
|
||||||
<entry>reserved</entry>
|
<entry>reserved</entry>
|
||||||
<entry></entry>
|
<entry></entry>
|
||||||
</row>
|
</row>
|
||||||
@ -370,7 +376,7 @@
|
|||||||
</row>
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry><token>CALLED</token></entry>
|
<entry><token>CALLED</token></entry>
|
||||||
<entry></entry>
|
<entry>non-reserved</entry>
|
||||||
<entry>non-reserved</entry>
|
<entry>non-reserved</entry>
|
||||||
<entry></entry>
|
<entry></entry>
|
||||||
</row>
|
</row>
|
||||||
@ -490,7 +496,7 @@
|
|||||||
</row>
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry><token>CLASS</token></entry>
|
<entry><token>CLASS</token></entry>
|
||||||
<entry></entry>
|
<entry>non-reserved</entry>
|
||||||
<entry>reserved</entry>
|
<entry>reserved</entry>
|
||||||
<entry></entry>
|
<entry></entry>
|
||||||
</row>
|
</row>
|
||||||
@ -680,6 +686,12 @@
|
|||||||
<entry>reserved</entry>
|
<entry>reserved</entry>
|
||||||
<entry>reserved</entry>
|
<entry>reserved</entry>
|
||||||
</row>
|
</row>
|
||||||
|
<row>
|
||||||
|
<entry><token>CONVERSION</token></entry>
|
||||||
|
<entry>non-reserved</entry>
|
||||||
|
<entry></entry>
|
||||||
|
<entry></entry>
|
||||||
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry><token>CONVERT</token></entry>
|
<entry><token>CONVERT</token></entry>
|
||||||
<entry>non-reserved (cannot be function or type)</entry>
|
<entry>non-reserved (cannot be function or type)</entry>
|
||||||
@ -706,7 +718,7 @@
|
|||||||
</row>
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry><token>CREATE</token></entry>
|
<entry><token>CREATE</token></entry>
|
||||||
<entry>non-reserved</entry>
|
<entry>reserved</entry>
|
||||||
<entry>reserved</entry>
|
<entry>reserved</entry>
|
||||||
<entry>reserved</entry>
|
<entry>reserved</entry>
|
||||||
</row>
|
</row>
|
||||||
@ -832,7 +844,7 @@
|
|||||||
</row>
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry><token>DEALLOCATE</token></entry>
|
<entry><token>DEALLOCATE</token></entry>
|
||||||
<entry></entry>
|
<entry>non-reserved</entry>
|
||||||
<entry>reserved</entry>
|
<entry>reserved</entry>
|
||||||
<entry>reserved</entry>
|
<entry>reserved</entry>
|
||||||
</row>
|
</row>
|
||||||
@ -880,7 +892,7 @@
|
|||||||
</row>
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry><token>DEFINER</token></entry>
|
<entry><token>DEFINER</token></entry>
|
||||||
<entry></entry>
|
<entry>non-reserved</entry>
|
||||||
<entry>non-reserved</entry>
|
<entry>non-reserved</entry>
|
||||||
<entry></entry>
|
<entry></entry>
|
||||||
</row>
|
</row>
|
||||||
@ -988,7 +1000,7 @@
|
|||||||
</row>
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry><token>DOMAIN</token></entry>
|
<entry><token>DOMAIN</token></entry>
|
||||||
<entry></entry>
|
<entry>non-reserved</entry>
|
||||||
<entry>reserved</entry>
|
<entry>reserved</entry>
|
||||||
<entry>reserved</entry>
|
<entry>reserved</entry>
|
||||||
</row>
|
</row>
|
||||||
@ -1126,7 +1138,7 @@
|
|||||||
</row>
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry><token>EXTERNAL</token></entry>
|
<entry><token>EXTERNAL</token></entry>
|
||||||
<entry></entry>
|
<entry>non-reserved</entry>
|
||||||
<entry>reserved</entry>
|
<entry>reserved</entry>
|
||||||
<entry>reserved</entry>
|
<entry>reserved</entry>
|
||||||
</row>
|
</row>
|
||||||
@ -1252,7 +1264,7 @@
|
|||||||
</row>
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry><token>GET</token></entry>
|
<entry><token>GET</token></entry>
|
||||||
<entry></entry>
|
<entry>non-reserved</entry>
|
||||||
<entry>reserved</entry>
|
<entry>reserved</entry>
|
||||||
<entry>reserved</entry>
|
<entry>reserved</entry>
|
||||||
</row>
|
</row>
|
||||||
@ -1276,7 +1288,7 @@
|
|||||||
</row>
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry><token>GRANT</token></entry>
|
<entry><token>GRANT</token></entry>
|
||||||
<entry>non-reserved</entry>
|
<entry>reserved</entry>
|
||||||
<entry>reserved</entry>
|
<entry>reserved</entry>
|
||||||
<entry>reserved</entry>
|
<entry>reserved</entry>
|
||||||
</row>
|
</row>
|
||||||
@ -1358,12 +1370,24 @@
|
|||||||
<entry>reserved</entry>
|
<entry>reserved</entry>
|
||||||
<entry>reserved</entry>
|
<entry>reserved</entry>
|
||||||
</row>
|
</row>
|
||||||
|
<row>
|
||||||
|
<entry><token>IMMUTABLE</token></entry>
|
||||||
|
<entry>non-reserved</entry>
|
||||||
|
<entry></entry>
|
||||||
|
<entry></entry>
|
||||||
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry><token>IMPLEMENTATION</token></entry>
|
<entry><token>IMPLEMENTATION</token></entry>
|
||||||
<entry></entry>
|
<entry></entry>
|
||||||
<entry>non-reserved</entry>
|
<entry>non-reserved</entry>
|
||||||
<entry></entry>
|
<entry></entry>
|
||||||
</row>
|
</row>
|
||||||
|
<row>
|
||||||
|
<entry><token>IMPLICIT</token></entry>
|
||||||
|
<entry>non-reserved</entry>
|
||||||
|
<entry></entry>
|
||||||
|
<entry></entry>
|
||||||
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry><token>IN</token></entry>
|
<entry><token>IN</token></entry>
|
||||||
<entry>reserved (can be function)</entry>
|
<entry>reserved (can be function)</entry>
|
||||||
@ -1426,7 +1450,7 @@
|
|||||||
</row>
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry><token>INPUT</token></entry>
|
<entry><token>INPUT</token></entry>
|
||||||
<entry></entry>
|
<entry>non-reserved</entry>
|
||||||
<entry>reserved</entry>
|
<entry>reserved</entry>
|
||||||
<entry>reserved</entry>
|
<entry>reserved</entry>
|
||||||
</row>
|
</row>
|
||||||
@ -1462,13 +1486,13 @@
|
|||||||
</row>
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry><token>INT</token></entry>
|
<entry><token>INT</token></entry>
|
||||||
<entry></entry>
|
<entry>non-reserved (cannot be function or type)</entry>
|
||||||
<entry>reserved</entry>
|
<entry>reserved</entry>
|
||||||
<entry>reserved</entry>
|
<entry>reserved</entry>
|
||||||
</row>
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry><token>INTEGER</token></entry>
|
<entry><token>INTEGER</token></entry>
|
||||||
<entry></entry>
|
<entry>non-reserved (cannot be function or type)</entry>
|
||||||
<entry>reserved</entry>
|
<entry>reserved</entry>
|
||||||
<entry>reserved</entry>
|
<entry>reserved</entry>
|
||||||
</row>
|
</row>
|
||||||
@ -1492,7 +1516,7 @@
|
|||||||
</row>
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry><token>INVOKER</token></entry>
|
<entry><token>INVOKER</token></entry>
|
||||||
<entry></entry>
|
<entry>non-reserved</entry>
|
||||||
<entry>non-reserved</entry>
|
<entry>non-reserved</entry>
|
||||||
<entry></entry>
|
<entry></entry>
|
||||||
</row>
|
</row>
|
||||||
@ -1642,13 +1666,13 @@
|
|||||||
</row>
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry><token>LOCALTIME</token></entry>
|
<entry><token>LOCALTIME</token></entry>
|
||||||
<entry></entry>
|
<entry>reserved</entry>
|
||||||
<entry>reserved</entry>
|
<entry>reserved</entry>
|
||||||
<entry></entry>
|
<entry></entry>
|
||||||
</row>
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry><token>LOCALTIMESTAMP</token></entry>
|
<entry><token>LOCALTIMESTAMP</token></entry>
|
||||||
<entry></entry>
|
<entry>reserved</entry>
|
||||||
<entry>reserved</entry>
|
<entry>reserved</entry>
|
||||||
<entry></entry>
|
<entry></entry>
|
||||||
</row>
|
</row>
|
||||||
@ -2056,7 +2080,7 @@
|
|||||||
</row>
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry><token>OVERLAY</token></entry>
|
<entry><token>OVERLAY</token></entry>
|
||||||
<entry></entry>
|
<entry>non-reserved (cannot be function or type)</entry>
|
||||||
<entry>non-reserved</entry>
|
<entry>non-reserved</entry>
|
||||||
<entry></entry>
|
<entry></entry>
|
||||||
</row>
|
</row>
|
||||||
@ -2156,6 +2180,12 @@
|
|||||||
<entry></entry>
|
<entry></entry>
|
||||||
<entry></entry>
|
<entry></entry>
|
||||||
</row>
|
</row>
|
||||||
|
<row>
|
||||||
|
<entry><token>PLACING</token></entry>
|
||||||
|
<entry>reserved</entry>
|
||||||
|
<entry></entry>
|
||||||
|
<entry></entry>
|
||||||
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry><token>PLI</token></entry>
|
<entry><token>PLI</token></entry>
|
||||||
<entry></entry>
|
<entry></entry>
|
||||||
@ -2194,7 +2224,7 @@
|
|||||||
</row>
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry><token>PREPARE</token></entry>
|
<entry><token>PREPARE</token></entry>
|
||||||
<entry></entry>
|
<entry>non-reserved</entry>
|
||||||
<entry>reserved</entry>
|
<entry>reserved</entry>
|
||||||
<entry>reserved</entry>
|
<entry>reserved</entry>
|
||||||
</row>
|
</row>
|
||||||
@ -2236,7 +2266,7 @@
|
|||||||
</row>
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry><token>PUBLIC</token></entry>
|
<entry><token>PUBLIC</token></entry>
|
||||||
<entry>reserved (can be function)</entry>
|
<entry></entry>
|
||||||
<entry>reserved</entry>
|
<entry>reserved</entry>
|
||||||
<entry>reserved</entry>
|
<entry>reserved</entry>
|
||||||
</row>
|
</row>
|
||||||
@ -2254,9 +2284,15 @@
|
|||||||
</row>
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry><token>REAL</token></entry>
|
<entry><token>REAL</token></entry>
|
||||||
|
<entry>non-reserved (cannot be function or type)</entry>
|
||||||
|
<entry>reserved</entry>
|
||||||
|
<entry>reserved</entry>
|
||||||
|
</row>
|
||||||
|
<row>
|
||||||
|
<entry><token>RECHECK</token></entry>
|
||||||
|
<entry>non-reserved</entry>
|
||||||
|
<entry></entry>
|
||||||
<entry></entry>
|
<entry></entry>
|
||||||
<entry>reserved</entry>
|
|
||||||
<entry>reserved</entry>
|
|
||||||
</row>
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry><token>RECURSIVE</token></entry>
|
<entry><token>RECURSIVE</token></entry>
|
||||||
@ -2416,7 +2452,7 @@
|
|||||||
</row>
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry><token>ROW</token></entry>
|
<entry><token>ROW</token></entry>
|
||||||
<entry>non-reserved</entry>
|
<entry>non-reserved (cannot be function or type)</entry>
|
||||||
<entry>reserved</entry>
|
<entry>reserved</entry>
|
||||||
<entry></entry>
|
<entry></entry>
|
||||||
</row>
|
</row>
|
||||||
@ -2494,7 +2530,7 @@
|
|||||||
</row>
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry><token>SECURITY</token></entry>
|
<entry><token>SECURITY</token></entry>
|
||||||
<entry></entry>
|
<entry>non-reserved</entry>
|
||||||
<entry>non-reserved</entry>
|
<entry>non-reserved</entry>
|
||||||
<entry></entry>
|
<entry></entry>
|
||||||
</row>
|
</row>
|
||||||
@ -2578,13 +2614,13 @@
|
|||||||
</row>
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry><token>SIMILAR</token></entry>
|
<entry><token>SIMILAR</token></entry>
|
||||||
<entry></entry>
|
<entry>reserved (can be function)</entry>
|
||||||
<entry>non-reserved</entry>
|
<entry>non-reserved</entry>
|
||||||
<entry></entry>
|
<entry></entry>
|
||||||
</row>
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry><token>SIMPLE</token></entry>
|
<entry><token>SIMPLE</token></entry>
|
||||||
<entry></entry>
|
<entry>non-reserved</entry>
|
||||||
<entry>non-reserved</entry>
|
<entry>non-reserved</entry>
|
||||||
<entry></entry>
|
<entry></entry>
|
||||||
</row>
|
</row>
|
||||||
@ -2596,7 +2632,7 @@
|
|||||||
</row>
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry><token>SMALLINT</token></entry>
|
<entry><token>SMALLINT</token></entry>
|
||||||
<entry></entry>
|
<entry>non-reserved (cannot be function or type)</entry>
|
||||||
<entry>reserved</entry>
|
<entry>reserved</entry>
|
||||||
<entry>reserved</entry>
|
<entry>reserved</entry>
|
||||||
</row>
|
</row>
|
||||||
@ -2672,6 +2708,12 @@
|
|||||||
<entry>reserved</entry>
|
<entry>reserved</entry>
|
||||||
<entry></entry>
|
<entry></entry>
|
||||||
</row>
|
</row>
|
||||||
|
<row>
|
||||||
|
<entry><token>STABLE</token></entry>
|
||||||
|
<entry>non-reserved</entry>
|
||||||
|
<entry></entry>
|
||||||
|
<entry></entry>
|
||||||
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry><token>START</token></entry>
|
<entry><token>START</token></entry>
|
||||||
<entry>non-reserved</entry>
|
<entry>non-reserved</entry>
|
||||||
@ -2714,6 +2756,18 @@
|
|||||||
<entry></entry>
|
<entry></entry>
|
||||||
<entry></entry>
|
<entry></entry>
|
||||||
</row>
|
</row>
|
||||||
|
<row>
|
||||||
|
<entry><token>STORAGE</token></entry>
|
||||||
|
<entry>non-reserved</entry>
|
||||||
|
<entry></entry>
|
||||||
|
<entry></entry>
|
||||||
|
</row>
|
||||||
|
<row>
|
||||||
|
<entry><token>STRICT</token></entry>
|
||||||
|
<entry>non-reserved</entry>
|
||||||
|
<entry></entry>
|
||||||
|
<entry></entry>
|
||||||
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry><token>STRUCTURE</token></entry>
|
<entry><token>STRUCTURE</token></entry>
|
||||||
<entry></entry>
|
<entry></entry>
|
||||||
@ -2914,7 +2968,7 @@
|
|||||||
</row>
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry><token>TREAT</token></entry>
|
<entry><token>TREAT</token></entry>
|
||||||
<entry></entry>
|
<entry>non-reserved (cannot be function or type)</entry>
|
||||||
<entry>reserved</entry>
|
<entry>reserved</entry>
|
||||||
<entry></entry>
|
<entry></entry>
|
||||||
</row>
|
</row>
|
||||||
@ -3046,7 +3100,7 @@
|
|||||||
</row>
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry><token>USAGE</token></entry>
|
<entry><token>USAGE</token></entry>
|
||||||
<entry></entry>
|
<entry>non-reserved</entry>
|
||||||
<entry>reserved</entry>
|
<entry>reserved</entry>
|
||||||
<entry>reserved</entry>
|
<entry>reserved</entry>
|
||||||
</row>
|
</row>
|
||||||
@ -3092,6 +3146,12 @@
|
|||||||
<entry></entry>
|
<entry></entry>
|
||||||
<entry></entry>
|
<entry></entry>
|
||||||
</row>
|
</row>
|
||||||
|
<row>
|
||||||
|
<entry><token>VALIDATOR</token></entry>
|
||||||
|
<entry>non-reserved</entry>
|
||||||
|
<entry></entry>
|
||||||
|
<entry></entry>
|
||||||
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry><token>VALUE</token></entry>
|
<entry><token>VALUE</token></entry>
|
||||||
<entry></entry>
|
<entry></entry>
|
||||||
@ -3140,6 +3200,12 @@
|
|||||||
<entry>reserved</entry>
|
<entry>reserved</entry>
|
||||||
<entry>reserved</entry>
|
<entry>reserved</entry>
|
||||||
</row>
|
</row>
|
||||||
|
<row>
|
||||||
|
<entry><token>VOLATILE</token></entry>
|
||||||
|
<entry>non-reserved</entry>
|
||||||
|
<entry></entry>
|
||||||
|
<entry></entry>
|
||||||
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry><token>WHEN</token></entry>
|
<entry><token>WHEN</token></entry>
|
||||||
<entry>reserved</entry>
|
<entry>reserved</entry>
|
||||||
@ -3178,7 +3244,7 @@
|
|||||||
</row>
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry><token>WRITE</token></entry>
|
<entry><token>WRITE</token></entry>
|
||||||
<entry></entry>
|
<entry>non-reserved</entry>
|
||||||
<entry>reserved</entry>
|
<entry>reserved</entry>
|
||||||
<entry>reserved</entry>
|
<entry>reserved</entry>
|
||||||
</row>
|
</row>
|
||||||
|
@ -1,5 +1,5 @@
|
|||||||
<!--
|
<!--
|
||||||
$Header: /cvsroot/pgsql/doc/src/sgml/libpq.sgml,v 1.100 2002/11/10 00:14:22 momjian Exp $
|
$Header: /cvsroot/pgsql/doc/src/sgml/libpq.sgml,v 1.101 2002/11/11 20:14:03 petere Exp $
|
||||||
-->
|
-->
|
||||||
|
|
||||||
<chapter id="libpq">
|
<chapter id="libpq">
|
||||||
@ -2139,22 +2139,23 @@ for information on correct values for these environment variables.
|
|||||||
<primary>password</primary>
|
<primary>password</primary>
|
||||||
<secondary>.pgpass</secondary>
|
<secondary>.pgpass</secondary>
|
||||||
</indexterm>
|
</indexterm>
|
||||||
<filename>$HOME/.pgpass</filename> is a file that can contain passwords
|
The file <filename>.pgpass</filename> in the home directory is a file
|
||||||
to be used if the connection requires a password. This file should have the
|
that can contain passwords to be used if the connection requires a
|
||||||
format:
|
password. This file should have the format:
|
||||||
<screen>
|
<synopsis>
|
||||||
<replaceable>hostname</replaceable>:<replaceable>port</replaceable>:<replaceable>database</replaceable>:<replaceable>username</replaceable>:<replaceable>password</replaceable>
|
<replaceable>hostname</replaceable>:<replaceable>port</replaceable>:<replaceable>database</replaceable>:<replaceable>username</replaceable>:<replaceable>password</replaceable>
|
||||||
</screen>
|
</synopsis>
|
||||||
Any of these may be a literal name, or <literal>*</literal>, which matches
|
Any of these may be a literal name, or <literal>*</literal>, which matches
|
||||||
anything. The first match will be used so put more specific entries first.
|
anything. The first match will be used so put more specific entries first.
|
||||||
Entries with <literal>:</literal> or <literal>\</literal> should be escaped
|
Entries with <literal>:</literal> or <literal>\</literal> should be escaped
|
||||||
with <literal>\</literal>.
|
with <literal>\</literal>.
|
||||||
</para>
|
</para>
|
||||||
<para>
|
<para>
|
||||||
The permissions on <filename>$HOME/.pgpass</filename> must disallow any
|
The permissions on <filename>.pgpass</filename> must disallow any
|
||||||
access to world or group; achieve this by the command
|
access to world or group; achieve this by the command
|
||||||
<command>chmod 0600 $HOME/.pgaccess</command>.
|
<command>chmod 0600 .pgaccess</command>.
|
||||||
If the permissions are less strict than this, the file will be ignored.
|
If the permissions are less strict than this, the file will be ignored.
|
||||||
|
</para>
|
||||||
</sect1>
|
</sect1>
|
||||||
|
|
||||||
<sect1 id="libpq-threading">
|
<sect1 id="libpq-threading">
|
||||||
|
@ -1,5 +1,5 @@
|
|||||||
<!--
|
<!--
|
||||||
$Header: /cvsroot/pgsql/doc/src/sgml/maintenance.sgml,v 1.19 2002/09/21 18:32:53 petere Exp $
|
$Header: /cvsroot/pgsql/doc/src/sgml/maintenance.sgml,v 1.20 2002/11/11 20:14:03 petere Exp $
|
||||||
-->
|
-->
|
||||||
|
|
||||||
<chapter id="maintenance">
|
<chapter id="maintenance">
|
||||||
@ -13,7 +13,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/maintenance.sgml,v 1.19 2002/09/21 18:32:53
|
|||||||
a regular basis to keep a <productname>PostgreSQL</productname>
|
a regular basis to keep a <productname>PostgreSQL</productname>
|
||||||
installation running smoothly. The tasks discussed here are repetitive
|
installation running smoothly. The tasks discussed here are repetitive
|
||||||
in nature and can easily be automated using standard Unix tools such
|
in nature and can easily be automated using standard Unix tools such
|
||||||
as <filename>cron</filename> scripts. But it is the database
|
as <application>cron</application> scripts. But it is the database
|
||||||
administrator's responsibility to set up appropriate scripts, and to
|
administrator's responsibility to set up appropriate scripts, and to
|
||||||
check that they execute successfully.
|
check that they execute successfully.
|
||||||
</para>
|
</para>
|
||||||
@ -104,7 +104,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/maintenance.sgml,v 1.19 2002/09/21 18:32:53
|
|||||||
<command>UPDATE</> or <command>DELETE</> of a row does not
|
<command>UPDATE</> or <command>DELETE</> of a row does not
|
||||||
immediately remove the old <firstterm>tuple</> (version of the row).
|
immediately remove the old <firstterm>tuple</> (version of the row).
|
||||||
This approach is necessary to gain the benefits of multiversion
|
This approach is necessary to gain the benefits of multiversion
|
||||||
concurrency control (see the <citetitle>User's Guide</>): the tuple
|
concurrency control (see the &cite-user;): the tuple
|
||||||
must not be deleted while it is still potentially visible to other
|
must not be deleted while it is still potentially visible to other
|
||||||
transactions. But eventually, an outdated or deleted tuple is no
|
transactions. But eventually, an outdated or deleted tuple is no
|
||||||
longer of interest to any transaction. The space it occupies must be
|
longer of interest to any transaction. The space it occupies must be
|
||||||
@ -206,7 +206,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/maintenance.sgml,v 1.19 2002/09/21 18:32:53
|
|||||||
Although per-column tweaking of <command>ANALYZE</> frequency may not be
|
Although per-column tweaking of <command>ANALYZE</> frequency may not be
|
||||||
very productive, you may well find it worthwhile to do per-column
|
very productive, you may well find it worthwhile to do per-column
|
||||||
adjustment of the level of detail of the statistics collected by
|
adjustment of the level of detail of the statistics collected by
|
||||||
<command>ANALYZE</>. Columns that are heavily used in WHERE clauses
|
<command>ANALYZE</>. Columns that are heavily used in <literal>WHERE</> clauses
|
||||||
and have highly irregular data distributions may require a finer-grain
|
and have highly irregular data distributions may require a finer-grain
|
||||||
data histogram than other columns. See <command>ALTER TABLE SET
|
data histogram than other columns. See <command>ALTER TABLE SET
|
||||||
STATISTICS</>.
|
STATISTICS</>.
|
||||||
@ -299,7 +299,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/maintenance.sgml,v 1.19 2002/09/21 18:32:53
|
|||||||
is exactly one billion transactions: if you wait longer, it's possible
|
is exactly one billion transactions: if you wait longer, it's possible
|
||||||
that a tuple that was not quite old enough to be reassigned last time
|
that a tuple that was not quite old enough to be reassigned last time
|
||||||
is now more than two billion transactions old and has wrapped around
|
is now more than two billion transactions old and has wrapped around
|
||||||
into the future --- ie, is lost to you. (Of course, it'll reappear
|
into the future --- i.e., is lost to you. (Of course, it'll reappear
|
||||||
after another two billion transactions, but that's no help.)
|
after another two billion transactions, but that's no help.)
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
@ -311,17 +311,17 @@ $Header: /cvsroot/pgsql/doc/src/sgml/maintenance.sgml,v 1.19 2002/09/21 18:32:53
|
|||||||
statistics in the system table <filename>pg_database</>. In particular,
|
statistics in the system table <filename>pg_database</>. In particular,
|
||||||
the <filename>datfrozenxid</> field of a database's
|
the <filename>datfrozenxid</> field of a database's
|
||||||
<filename>pg_database</> row is updated at the completion of any
|
<filename>pg_database</> row is updated at the completion of any
|
||||||
database-wide vacuum operation (ie, <command>VACUUM</> that does not
|
database-wide vacuum operation (i.e., <command>VACUUM</> that does not
|
||||||
name a specific table). The value stored in this field is the freeze
|
name a specific table). The value stored in this field is the freeze
|
||||||
cutoff XID that was used by that <command>VACUUM</> command. All normal
|
cutoff XID that was used by that <command>VACUUM</> command. All normal
|
||||||
XIDs older than this cutoff XID are guaranteed to have been replaced by
|
XIDs older than this cutoff XID are guaranteed to have been replaced by
|
||||||
<literal>FrozenXID</> within that database. A convenient way to
|
<literal>FrozenXID</> within that database. A convenient way to
|
||||||
examine this information is to execute the query
|
examine this information is to execute the query
|
||||||
<informalexample>
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
SELECT datname, age(datfrozenxid) FROM pg_database;
|
SELECT datname, age(datfrozenxid) FROM pg_database;
|
||||||
</programlisting>
|
</programlisting>
|
||||||
</informalexample>
|
|
||||||
The <literal>age</> column measures the number of transactions from the
|
The <literal>age</> column measures the number of transactions from the
|
||||||
cutoff XID to the current transaction's XID.
|
cutoff XID to the current transaction's XID.
|
||||||
</para>
|
</para>
|
||||||
@ -336,7 +336,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
|
|||||||
each database-wide <command>VACUUM</> automatically delivers a warning
|
each database-wide <command>VACUUM</> automatically delivers a warning
|
||||||
if there are any <filename>pg_database</> entries showing an
|
if there are any <filename>pg_database</> entries showing an
|
||||||
<literal>age</> of more than 1.5 billion transactions, for example:
|
<literal>age</> of more than 1.5 billion transactions, for example:
|
||||||
<informalexample>
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
play=# vacuum;
|
play=# vacuum;
|
||||||
WARNING: Some databases have not been vacuumed in 1613770184 transactions.
|
WARNING: Some databases have not been vacuumed in 1613770184 transactions.
|
||||||
@ -344,7 +344,6 @@ WARNING: Some databases have not been vacuumed in 1613770184 transactions.
|
|||||||
or you may have a wraparound failure.
|
or you may have a wraparound failure.
|
||||||
VACUUM
|
VACUUM
|
||||||
</programlisting>
|
</programlisting>
|
||||||
</informalexample>
|
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
|
@ -1,5 +1,5 @@
|
|||||||
<!--
|
<!--
|
||||||
$Header: /cvsroot/pgsql/doc/src/sgml/manage-ag.sgml,v 2.22 2002/10/24 17:48:54 petere Exp $
|
$Header: /cvsroot/pgsql/doc/src/sgml/manage-ag.sgml,v 2.23 2002/11/11 20:14:03 petere Exp $
|
||||||
-->
|
-->
|
||||||
|
|
||||||
<chapter id="managing-databases">
|
<chapter id="managing-databases">
|
||||||
@ -27,7 +27,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/manage-ag.sgml,v 2.22 2002/10/24 17:48:54 p
|
|||||||
database within the installation.) More accurately, a database is
|
database within the installation.) More accurately, a database is
|
||||||
a collection of schemas and the schemas contain the tables,
|
a collection of schemas and the schemas contain the tables,
|
||||||
functions, etc. So the full hierarchy is:
|
functions, etc. So the full hierarchy is:
|
||||||
server-database-schema-table (or something else instead of a
|
server, database, schema, table (or something else instead of a
|
||||||
table).
|
table).
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
|
@ -1,12 +1,12 @@
|
|||||||
<!--
|
<!--
|
||||||
$Header: /cvsroot/pgsql/doc/src/sgml/monitoring.sgml,v 1.14 2002/09/21 18:32:53 petere Exp $
|
$Header: /cvsroot/pgsql/doc/src/sgml/monitoring.sgml,v 1.15 2002/11/11 20:14:03 petere Exp $
|
||||||
-->
|
-->
|
||||||
|
|
||||||
<chapter id="monitoring">
|
<chapter id="monitoring">
|
||||||
<title>Monitoring Database Activity</title>
|
<title>Monitoring Database Activity</title>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
A database administrator frequently wonders <quote>what is the system
|
A database administrator frequently wonders, <quote>What is the system
|
||||||
doing right now?</quote>
|
doing right now?</quote>
|
||||||
This chapter discusses how to find that out.
|
This chapter discusses how to find that out.
|
||||||
</para>
|
</para>
|
||||||
@ -19,7 +19,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/monitoring.sgml,v 1.14 2002/09/21 18:32:53
|
|||||||
<command>ps</> and <command>top</>. Also, once one has identified a
|
<command>ps</> and <command>top</>. Also, once one has identified a
|
||||||
poorly-performing query, further investigation may be needed using
|
poorly-performing query, further investigation may be needed using
|
||||||
<productname>PostgreSQL</productname>'s <command>EXPLAIN</> command.
|
<productname>PostgreSQL</productname>'s <command>EXPLAIN</> command.
|
||||||
The <citetitle>User's Guide</citetitle> discusses <command>EXPLAIN</>
|
The &cite-user; discusses <command>EXPLAIN</>
|
||||||
and other methods for understanding the behavior of an individual
|
and other methods for understanding the behavior of an individual
|
||||||
query.
|
query.
|
||||||
</para>
|
</para>
|
||||||
@ -64,8 +64,8 @@ postgres: <replaceable>user</> <replaceable>database</> <replaceable>host</> <re
|
|||||||
|
|
||||||
The user, database, and connection source host items remain the same for
|
The user, database, and connection source host items remain the same for
|
||||||
the life of the client connection, but the activity indicator changes.
|
the life of the client connection, but the activity indicator changes.
|
||||||
The activity may be <literal>idle</> (ie, waiting for a client command),
|
The activity may be <literal>idle</> (i.e., waiting for a client command),
|
||||||
<literal>idle in transaction</> (waiting for client inside a BEGIN block),
|
<literal>idle in transaction</> (waiting for client inside a <command>BEGIN</> block),
|
||||||
or a command type name such as <literal>SELECT</>. Also,
|
or a command type name such as <literal>SELECT</>. Also,
|
||||||
<literal>waiting</> is attached if the server is presently waiting
|
<literal>waiting</> is attached if the server is presently waiting
|
||||||
on a lock held by another server process. In the above example we can infer
|
on a lock held by another server process. In the above example we can infer
|
||||||
@ -149,7 +149,7 @@ postgres: <replaceable>user</> <replaceable>database</> <replaceable>host</> <re
|
|||||||
<varname>STATS_BLOCK_LEVEL</varname>,
|
<varname>STATS_BLOCK_LEVEL</varname>,
|
||||||
and <varname>STATS_ROW_LEVEL</varname>
|
and <varname>STATS_ROW_LEVEL</varname>
|
||||||
default to <literal>false</>, no statistics are actually collected
|
default to <literal>false</>, no statistics are actually collected
|
||||||
in the default configuration! You must turn one or more of them on
|
in the default configuration. You must turn one or more of them on
|
||||||
before you will get useful results from the statistical display
|
before you will get useful results from the statistical display
|
||||||
functions.
|
functions.
|
||||||
</para>
|
</para>
|
||||||
@ -162,8 +162,9 @@ postgres: <replaceable>user</> <replaceable>database</> <replaceable>host</> <re
|
|||||||
|
|
||||||
<para>
|
<para>
|
||||||
Several predefined views are available to show the results of
|
Several predefined views are available to show the results of
|
||||||
statistics collection. Alternatively, one can build custom views
|
statistics collection, listed in <xref
|
||||||
using the underlying statistics functions.
|
linkend="monitoring-stats-views-table">. Alternatively, one can
|
||||||
|
build custom views using the underlying statistics functions.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
@ -172,8 +173,8 @@ postgres: <replaceable>user</> <replaceable>database</> <replaceable>host</> <re
|
|||||||
Each individual server process transmits new access counts to the collector
|
Each individual server process transmits new access counts to the collector
|
||||||
just before waiting for another client command; so a query still in
|
just before waiting for another client command; so a query still in
|
||||||
progress does not affect the displayed totals. Also, the collector itself
|
progress does not affect the displayed totals. Also, the collector itself
|
||||||
emits new totals at most once per <varname>pgstat_stat_interval</varname> (500 milliseconds
|
emits new totals at most once per <varname>pgstat_stat_interval</varname> milliseconds
|
||||||
by default). So the displayed totals lag behind actual activity.
|
(500 by default). So the displayed totals lag behind actual activity.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
@ -190,7 +191,7 @@ postgres: <replaceable>user</> <replaceable>database</> <replaceable>host</> <re
|
|||||||
block.
|
block.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<table>
|
<table id="monitoring-stats-views-table">
|
||||||
<title>Standard Statistics Views</title>
|
<title>Standard Statistics Views</title>
|
||||||
|
|
||||||
<tgroup cols="2">
|
<tgroup cols="2">
|
||||||
@ -204,9 +205,9 @@ postgres: <replaceable>user</> <replaceable>database</> <replaceable>host</> <re
|
|||||||
<tbody>
|
<tbody>
|
||||||
<row>
|
<row>
|
||||||
<entry><structname>pg_stat_activity</></entry>
|
<entry><structname>pg_stat_activity</></entry>
|
||||||
<entry>One row per server process, showing process <acronym>PID</>, database,
|
<entry>One row per server process, showing process <acronym>ID</>, database,
|
||||||
user, and current query. The current query column is only available
|
user, and current query. The current query column is only available
|
||||||
to superusers; for others it reads as NULL. (Note that because of
|
to superusers; for others it reads as null. (Note that because of
|
||||||
the collector's reporting delay, current query will only be up-to-date
|
the collector's reporting delay, current query will only be up-to-date
|
||||||
for long-running queries.)</entry>
|
for long-running queries.)</entry>
|
||||||
</row>
|
</row>
|
||||||
@ -215,7 +216,7 @@ postgres: <replaceable>user</> <replaceable>database</> <replaceable>host</> <re
|
|||||||
<entry><structname>pg_stat_database</></entry>
|
<entry><structname>pg_stat_database</></entry>
|
||||||
<entry>One row per database, showing number of active backends,
|
<entry>One row per database, showing number of active backends,
|
||||||
total transactions committed and total rolled back in that database,
|
total transactions committed and total rolled back in that database,
|
||||||
total disk blocks read, and total number of buffer hits (ie, block
|
total disk blocks read, and total number of buffer hits (i.e., block
|
||||||
read requests avoided by finding the block already in buffer cache).
|
read requests avoided by finding the block already in buffer cache).
|
||||||
</entry>
|
</entry>
|
||||||
</row>
|
</row>
|
||||||
@ -230,13 +231,13 @@ postgres: <replaceable>user</> <replaceable>database</> <replaceable>host</> <re
|
|||||||
|
|
||||||
<row>
|
<row>
|
||||||
<entry><structname>pg_stat_sys_tables</></entry>
|
<entry><structname>pg_stat_sys_tables</></entry>
|
||||||
<entry>Same as pg_stat_all_tables, except that only system tables
|
<entry>Same as <structname>pg_stat_all_tables</>, except that only system tables
|
||||||
are shown.</entry>
|
are shown.</entry>
|
||||||
</row>
|
</row>
|
||||||
|
|
||||||
<row>
|
<row>
|
||||||
<entry><structname>pg_stat_user_tables</></entry>
|
<entry><structname>pg_stat_user_tables</></entry>
|
||||||
<entry>Same as pg_stat_all_tables, except that only user tables
|
<entry>Same as <structname>pg_stat_all_tables</>, except that only user tables
|
||||||
are shown.</entry>
|
are shown.</entry>
|
||||||
</row>
|
</row>
|
||||||
|
|
||||||
@ -244,20 +245,20 @@ postgres: <replaceable>user</> <replaceable>database</> <replaceable>host</> <re
|
|||||||
<entry><structname>pg_stat_all_indexes</></entry>
|
<entry><structname>pg_stat_all_indexes</></entry>
|
||||||
<entry>For each index in the current database, the total number
|
<entry>For each index in the current database, the total number
|
||||||
of index scans that have used that index, the number of index tuples
|
of index scans that have used that index, the number of index tuples
|
||||||
read, and the number of successfully fetched heap tuples (this may
|
read, and the number of successfully fetched heap tuples. (This may
|
||||||
be less when there are index entries pointing to expired heap tuples).
|
be less when there are index entries pointing to expired heap tuples.)
|
||||||
</entry>
|
</entry>
|
||||||
</row>
|
</row>
|
||||||
|
|
||||||
<row>
|
<row>
|
||||||
<entry><structname>pg_stat_sys_indexes</></entry>
|
<entry><structname>pg_stat_sys_indexes</></entry>
|
||||||
<entry>Same as pg_stat_all_indexes, except that only indexes on
|
<entry>Same as <structname>pg_stat_all_indexes</>, except that only indexes on
|
||||||
system tables are shown.</entry>
|
system tables are shown.</entry>
|
||||||
</row>
|
</row>
|
||||||
|
|
||||||
<row>
|
<row>
|
||||||
<entry><structname>pg_stat_user_indexes</></entry>
|
<entry><structname>pg_stat_user_indexes</></entry>
|
||||||
<entry>Same as pg_stat_all_indexes, except that only indexes on
|
<entry>Same as <structname>pg_stat_all_indexes</>, except that only indexes on
|
||||||
user tables are shown.</entry>
|
user tables are shown.</entry>
|
||||||
</row>
|
</row>
|
||||||
|
|
||||||
@ -339,18 +340,19 @@ postgres: <replaceable>user</> <replaceable>database</> <replaceable>host</> <re
|
|||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
Other ways of looking at the statistics can be set up by writing queries
|
Other ways of looking at the statistics can be set up by writing
|
||||||
that use the same underlying statistics access functions as these standard
|
queries that use the same underlying statistics access functions as
|
||||||
views do. The per-database access functions accept a database OID to
|
these standard views do. These functions are listed in <xref
|
||||||
identify which database to report on. The per-table and per-index
|
linkend="monitoring-stats-funcs-table">. The per-database access
|
||||||
functions accept a table or index OID (note that only tables and indexes
|
functions accept a database OID to identify which database to
|
||||||
in the current
|
report on. The per-table and per-index functions accept 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
|
database can be seen with these functions). The per-backend access
|
||||||
functions accept a backend ID number, which ranges from one to the number
|
functions accept a backend ID number, which ranges from one to the
|
||||||
of currently active backends.
|
number of currently active backends.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<table>
|
<table id="monitoring-stats-funcs-table">
|
||||||
<title>Statistics Access Functions</title>
|
<title>Statistics Access Functions</title>
|
||||||
|
|
||||||
<tgroup cols="3">
|
<tgroup cols="3">
|
||||||
@ -531,11 +533,14 @@ postgres: <replaceable>user</> <replaceable>database</> <replaceable>host</> <re
|
|||||||
</tgroup>
|
</tgroup>
|
||||||
</table>
|
</table>
|
||||||
|
|
||||||
|
<note>
|
||||||
<para>
|
<para>
|
||||||
Note: blocks_fetched minus blocks_hit gives the number of kernel read()
|
Blocks_fetched minus blocks_hit gives the number of kernel
|
||||||
calls issued for the table, index, or database; but the actual number of
|
<function>read()</> calls issued for the table, index, or
|
||||||
physical reads is usually lower due to kernel-level buffering.
|
database; but the actual number of physical reads is usually
|
||||||
|
lower due to kernel-level buffering.
|
||||||
</para>
|
</para>
|
||||||
|
</note>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
The function <function>pg_stat_get_backend_idset</function> provides
|
The function <function>pg_stat_get_backend_idset</function> provides
|
||||||
@ -559,24 +564,27 @@ FROM (SELECT pg_stat_get_backend_idset() AS backendid) AS S;
|
|||||||
Another useful tool for monitoring database activity is the
|
Another useful tool for monitoring database activity is the
|
||||||
<literal>pg_locks</literal> system catalog. This allows the
|
<literal>pg_locks</literal> system catalog. This allows the
|
||||||
database administrator to view information about the outstanding
|
database administrator to view information about the outstanding
|
||||||
locks in the lock manager. For example, this capability can be
|
locks in the lock manager. For example, this capability can be used
|
||||||
used to:
|
to:
|
||||||
|
|
||||||
<itemizedlist>
|
<itemizedlist>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
View all the locks currently outstanding, all the locks on
|
View all the locks currently outstanding, all the locks on
|
||||||
relations in a particular database, all the locks on a
|
relations in a particular database, all the locks on a
|
||||||
particular relation, or all the locks held by a particular
|
particular relation, or all the locks held by a particular
|
||||||
<productname>PostgreSQL</productname> backend.
|
<productname>PostgreSQL</productname> session.
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
View the relation in the current database with the most
|
View the relation in the current database with the most
|
||||||
un-granted locks (which might be a source of contention among
|
ungranted locks (which might be a source of contention among
|
||||||
database clients).
|
database clients).
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
Determine the effect of lock contention on overall database
|
Determine the effect of lock contention on overall database
|
||||||
@ -587,16 +595,15 @@ FROM (SELECT pg_stat_get_backend_idset() AS backendid) AS S;
|
|||||||
</itemizedlist>
|
</itemizedlist>
|
||||||
|
|
||||||
For more information on locking and managing concurrency with
|
For more information on locking and managing concurrency with
|
||||||
<productname>PostgreSQL</productname>, refer to the
|
<productname>PostgreSQL</productname>, refer to the &cite-user;.
|
||||||
<citetitle>Administrator's Guide</citetitle>.
|
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<note>
|
<note>
|
||||||
<para>
|
<para>
|
||||||
When the <literal>pg_locks</literal> view is accessed, the
|
When the <literal>pg_locks</literal> view is accessed, the
|
||||||
internal lock manager data structures are momentarily locked,
|
internal lock manager data structures are momentarily locked, and
|
||||||
and a copy is made for the view to display. This ensures that
|
a copy is made for the view to display. This ensures that the
|
||||||
the view produces a consistent set of results, while not blocking
|
view produces a consistent set of results, while not blocking
|
||||||
normal lock manager operations longer than necessary. Nonetheless
|
normal lock manager operations longer than necessary. Nonetheless
|
||||||
there could be some impact on database performance if this view is
|
there could be some impact on database performance if this view is
|
||||||
examined often.
|
examined often.
|
||||||
@ -604,17 +611,19 @@ FROM (SELECT pg_stat_get_backend_idset() AS backendid) AS S;
|
|||||||
</note>
|
</note>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
The <literal>pg_locks</literal> view contains one row per lockable
|
<xref linkend="monitoring-locks-table"> shows the definition of the
|
||||||
object and requested lock mode. Thus, the same lockable object
|
<literal>pg_locks</literal> columns. The
|
||||||
may appear many times, if multiple transactions are holding or
|
<literal>pg_locks</literal> view contains one row per lockable
|
||||||
waiting for locks on it. A lockable object is either a relation
|
object and requested lock mode. Thus, the same lockable object may
|
||||||
or a transaction ID. (Note that this view includes only table-level
|
appear many times, if multiple transactions are holding or waiting
|
||||||
|
for locks on it. A lockable object is either a relation or a
|
||||||
|
transaction ID. (Note that this view includes only table-level
|
||||||
locks, not row-level ones. If a transaction is waiting for a
|
locks, not row-level ones. If a transaction is waiting for a
|
||||||
row-level lock, it will appear in the view as waiting for the
|
row-level lock, it will appear in the view as waiting for the
|
||||||
transaction ID of the current holder of that row lock.)
|
transaction ID of the current holder of that row lock.)
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<table>
|
<table id="monitoring-locks-table">
|
||||||
<title>Lock Status System View</title>
|
<title>Lock Status System View</title>
|
||||||
|
|
||||||
<tgroup cols="3">
|
<tgroup cols="3">
|
||||||
@ -630,23 +639,24 @@ FROM (SELECT pg_stat_get_backend_idset() AS backendid) AS S;
|
|||||||
<row>
|
<row>
|
||||||
<entry><structfield>relation</structfield></entry>
|
<entry><structfield>relation</structfield></entry>
|
||||||
<entry><type>oid</type></entry>
|
<entry><type>oid</type></entry>
|
||||||
<entry>The OID of the locked relation, or NULL if the lockable
|
<entry>
|
||||||
object is a transaction ID. This column can be joined
|
The OID of the locked relation, or null if the lockable object
|
||||||
with the <literal>pg_class</literal> system catalog to get more
|
is a transaction ID. This column can be joined with the
|
||||||
information on the locked relation. Note however that this will
|
<literal>pg_class</literal> system catalog to get more
|
||||||
only work for relations in the current database (those for which
|
information on the locked relation. Note however that this
|
||||||
the <structfield>database</structfield> column is either the
|
will only work for relations in the current database (those for
|
||||||
current database's OID or zero).
|
which the <structfield>database</structfield> column is either
|
||||||
|
the current database's OID or zero).
|
||||||
</entry>
|
</entry>
|
||||||
</row>
|
</row>
|
||||||
|
|
||||||
<row>
|
<row>
|
||||||
<entry><structfield>database</structfield></entry>
|
<entry><structfield>database</structfield></entry>
|
||||||
<entry><type>oid</type></entry>
|
<entry><type>oid</type></entry>
|
||||||
<entry>The OID of the database in which the locked relation
|
<entry>
|
||||||
exists, or NULL if the lockable object is a transaction ID.
|
The OID of the database in which the locked relation exists, or
|
||||||
If the lock is on a globally-shared table, this field will be
|
null if the lockable object is a transaction ID. If the lock
|
||||||
zero. This
|
is on a globally-shared table, this field will be zero. This
|
||||||
column can be joined with the <literal>pg_database</literal>
|
column can be joined with the <literal>pg_database</literal>
|
||||||
system catalog to get more information on the locked object's
|
system catalog to get more information on the locked object's
|
||||||
database.
|
database.
|
||||||
@ -656,48 +666,54 @@ FROM (SELECT pg_stat_get_backend_idset() AS backendid) AS S;
|
|||||||
<row>
|
<row>
|
||||||
<entry><structfield>transaction</structfield></entry>
|
<entry><structfield>transaction</structfield></entry>
|
||||||
<entry><type>xid</type></entry>
|
<entry><type>xid</type></entry>
|
||||||
<entry>The ID of a transaction, or NULL if the lockable object
|
<entry>
|
||||||
is a relation. Every transaction holds an exclusive lock on its
|
The ID of a transaction, or null if the lockable object is a
|
||||||
transaction ID for its entire duration. If one transaction finds
|
relation. Every transaction holds an exclusive lock on its
|
||||||
it necessary to wait specifically for another transaction, it
|
transaction ID for its entire duration. If one transaction
|
||||||
does so by attempting to acquire share lock on the other transaction
|
finds it necessary to wait specifically for another
|
||||||
ID. That will succeed only when the other transaction terminates
|
transaction, it does so by attempting to acquire share lock on
|
||||||
and releases its locks.
|
the other transaction ID. That will succeed only when the
|
||||||
|
other transaction terminates and releases its locks.
|
||||||
</entry>
|
</entry>
|
||||||
</row>
|
</row>
|
||||||
|
|
||||||
<row>
|
<row>
|
||||||
<entry><structfield>pid</structfield></entry>
|
<entry><structfield>pid</structfield></entry>
|
||||||
<entry><type>int4</type></entry>
|
<entry><type>integer</type></entry>
|
||||||
<entry>The process ID of the
|
<entry>
|
||||||
<productname>PostgreSQL</productname> backend that has
|
The process ID of the <productname>PostgreSQL</productname>
|
||||||
acquired or is attempting to acquire the lock. If you have
|
backend belonging to the session that has acquired or is
|
||||||
enabled the statistics collector, this column can be joined
|
attempting to acquire the lock. If you have enabled the
|
||||||
with the <literal>pg_stat_activity</literal> view to get
|
statistics collector, this column can be joined with the
|
||||||
more information on the backend holding or waiting to hold the
|
<literal>pg_stat_activity</literal> view to get more
|
||||||
lock.</entry>
|
information on the backend holding or waiting to hold the
|
||||||
|
lock.
|
||||||
|
</entry>
|
||||||
</row>
|
</row>
|
||||||
|
|
||||||
<row>
|
<row>
|
||||||
<entry><structfield>mode</structfield></entry>
|
<entry><structfield>mode</structfield></entry>
|
||||||
<entry><type>text</type></entry>
|
<entry><type>text</type></entry>
|
||||||
<entry>The mode of the requested or held lock on the lockable
|
<entry>
|
||||||
object. For more information on the
|
The mode of the requested or held lock on the lockable
|
||||||
different lock modes available in
|
object. For more information on the different lock modes
|
||||||
<productname>PostgreSQL</productname>, refer to the
|
available in <productname>PostgreSQL</productname>, refer to
|
||||||
<citetitle>User's Guide</citetitle>.</entry>
|
the &cite-user;.
|
||||||
|
</entry>
|
||||||
</row>
|
</row>
|
||||||
|
|
||||||
<row>
|
<row>
|
||||||
<entry><structfield>isgranted</structfield></entry>
|
<entry><structfield>isgranted</structfield></entry>
|
||||||
<entry><type>bool</type></entry>
|
<entry><type>boolean</type></entry>
|
||||||
<entry>True if this lock has been granted (is held by this
|
<entry>
|
||||||
backend). False indicates that this backend is currently
|
True if this lock has been granted (is held by this session).
|
||||||
waiting to acquire this lock, which implies that some other
|
False indicates that this session is currently waiting to
|
||||||
backend is holding a conflicting lock mode on the same lockable
|
acquire this lock, which implies that some other session is
|
||||||
object. This backend will sleep until the other lock is released
|
holding a conflicting lock mode on the same lockable object.
|
||||||
(or a deadlock situation is detected). A single backend can be
|
This backend will sleep until the other lock is released (or a
|
||||||
waiting to acquire at most one lock at a time.</entry>
|
deadlock situation is detected). A single backend can be
|
||||||
|
waiting to acquire at most one lock at a time.
|
||||||
|
</entry>
|
||||||
</row>
|
</row>
|
||||||
</tbody>
|
</tbody>
|
||||||
</tgroup>
|
</tgroup>
|
||||||
|
@ -1,5 +1,5 @@
|
|||||||
<!--
|
<!--
|
||||||
$Header: /cvsroot/pgsql/doc/src/sgml/mvcc.sgml,v 2.28 2002/09/21 18:32:53 petere Exp $
|
$Header: /cvsroot/pgsql/doc/src/sgml/mvcc.sgml,v 2.29 2002/11/11 20:14:03 petere Exp $
|
||||||
-->
|
-->
|
||||||
|
|
||||||
<chapter id="mvcc">
|
<chapter id="mvcc">
|
||||||
@ -9,24 +9,23 @@ $Header: /cvsroot/pgsql/doc/src/sgml/mvcc.sgml,v 2.28 2002/09/21 18:32:53 petere
|
|||||||
<primary>concurrency</primary>
|
<primary>concurrency</primary>
|
||||||
</indexterm>
|
</indexterm>
|
||||||
|
|
||||||
<abstract>
|
|
||||||
<para>
|
<para>
|
||||||
Multiversion Concurrency Control
|
This chapter describes the behavior of the PostgreSQL database
|
||||||
(MVCC)
|
system when two or more sessions try to access the same data at the
|
||||||
is an advanced technique for improving database performance in a
|
same time. The goals in that situation are to allow efficient
|
||||||
multiuser environment.
|
access for all sessions while maintaining strict data integrity.
|
||||||
Vadim Mikheev (<email>vadim@krs.ru</email>) provided
|
Every developer of database applications should be familiar with
|
||||||
the implementation for <productname>PostgreSQL</productname>.
|
the topics covered in this chapter.
|
||||||
</para>
|
</para>
|
||||||
</abstract>
|
|
||||||
|
|
||||||
<sect1 id="mvcc-intro">
|
<sect1 id="mvcc-intro">
|
||||||
<title>Introduction</title>
|
<title>Introduction</title>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
Unlike most other database systems which use locks for concurrency control,
|
Unlike traditional database systems which use locks for concurrency control,
|
||||||
<productname>PostgreSQL</productname>
|
<productname>PostgreSQL</productname>
|
||||||
maintains data consistency by using a multiversion model.
|
maintains data consistency by using a multiversion model
|
||||||
|
(Multiversion Concurrency Control, <acronym>MVCC</acronym>).
|
||||||
This means that while querying a database each transaction sees
|
This means that while querying a database each transaction sees
|
||||||
a snapshot of data (a <firstterm>database version</firstterm>)
|
a snapshot of data (a <firstterm>database version</firstterm>)
|
||||||
as it was some
|
as it was some
|
||||||
@ -56,7 +55,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/mvcc.sgml,v 2.28 2002/09/21 18:32:53 petere
|
|||||||
<title>Transaction Isolation</title>
|
<title>Transaction Isolation</title>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
The <acronym>ANSI</acronym>/<acronym>ISO</acronym> <acronym>SQL</acronym>
|
The <acronym>SQL</acronym>
|
||||||
standard defines four levels of transaction
|
standard defines four levels of transaction
|
||||||
isolation in terms of three phenomena that must be prevented
|
isolation in terms of three phenomena that must be prevented
|
||||||
between concurrent transactions.
|
between concurrent transactions.
|
||||||
@ -65,8 +64,8 @@ $Header: /cvsroot/pgsql/doc/src/sgml/mvcc.sgml,v 2.28 2002/09/21 18:32:53 petere
|
|||||||
<variablelist>
|
<variablelist>
|
||||||
<varlistentry>
|
<varlistentry>
|
||||||
<term>
|
<term>
|
||||||
dirty reads
|
dirty read
|
||||||
<indexterm><primary>dirty reads</primary></indexterm>
|
<indexterm><primary>dirty read</primary></indexterm>
|
||||||
</term>
|
</term>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
@ -77,8 +76,8 @@ $Header: /cvsroot/pgsql/doc/src/sgml/mvcc.sgml,v 2.28 2002/09/21 18:32:53 petere
|
|||||||
|
|
||||||
<varlistentry>
|
<varlistentry>
|
||||||
<term>
|
<term>
|
||||||
non-repeatable reads
|
nonrepeatable read
|
||||||
<indexterm><primary>non-repeatable reads</primary></indexterm>
|
<indexterm><primary>nonrepeatable read</primary></indexterm>
|
||||||
</term>
|
</term>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
@ -92,7 +91,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/mvcc.sgml,v 2.28 2002/09/21 18:32:53 petere
|
|||||||
<varlistentry>
|
<varlistentry>
|
||||||
<term>
|
<term>
|
||||||
phantom read
|
phantom read
|
||||||
<indexterm><primary>phantom reads</primary></indexterm>
|
<indexterm><primary>phantom read</primary></indexterm>
|
||||||
</term>
|
</term>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
@ -111,6 +110,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/mvcc.sgml,v 2.28 2002/09/21 18:32:53 petere
|
|||||||
</indexterm>
|
</indexterm>
|
||||||
The four transaction isolation levels and the corresponding
|
The four transaction isolation levels and the corresponding
|
||||||
behaviors are described in <xref linkend="mvcc-isolevel-table">.
|
behaviors are described in <xref linkend="mvcc-isolevel-table">.
|
||||||
|
</para>
|
||||||
|
|
||||||
<table tocentry="1" id="mvcc-isolevel-table">
|
<table tocentry="1" id="mvcc-isolevel-table">
|
||||||
<title><acronym>SQL</acronym> Transaction Isolation Levels</title>
|
<title><acronym>SQL</acronym> Transaction Isolation Levels</title>
|
||||||
@ -125,7 +125,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/mvcc.sgml,v 2.28 2002/09/21 18:32:53 petere
|
|||||||
Dirty Read
|
Dirty Read
|
||||||
</entry>
|
</entry>
|
||||||
<entry>
|
<entry>
|
||||||
Non-Repeatable Read
|
Nonrepeatable Read
|
||||||
</entry>
|
</entry>
|
||||||
<entry>
|
<entry>
|
||||||
Phantom Read
|
Phantom Read
|
||||||
@ -195,15 +195,13 @@ $Header: /cvsroot/pgsql/doc/src/sgml/mvcc.sgml,v 2.28 2002/09/21 18:32:53 petere
|
|||||||
</tbody>
|
</tbody>
|
||||||
</tgroup>
|
</tgroup>
|
||||||
</table>
|
</table>
|
||||||
</para>
|
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
<productname>PostgreSQL</productname>
|
<productname>PostgreSQL</productname>
|
||||||
offers the read committed and serializable isolation levels.
|
offers the read committed and serializable isolation levels.
|
||||||
</para>
|
</para>
|
||||||
</sect1>
|
|
||||||
|
|
||||||
<sect1 id="xact-read-committed">
|
<sect2 id="xact-read-committed">
|
||||||
<title>Read Committed Isolation Level</title>
|
<title>Read Committed Isolation Level</title>
|
||||||
|
|
||||||
<indexterm>
|
<indexterm>
|
||||||
@ -229,7 +227,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/mvcc.sgml,v 2.28 2002/09/21 18:32:53 petere
|
|||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
<command>UPDATE</command>, <command>DELETE</command> and <command>SELECT
|
<command>UPDATE</command>, <command>DELETE</command>, and <command>SELECT
|
||||||
FOR UPDATE</command> commands behave the same as <command>SELECT</command>
|
FOR UPDATE</command> commands behave the same as <command>SELECT</command>
|
||||||
in terms of searching for target rows: they will only find target rows
|
in terms of searching for target rows: they will only find target rows
|
||||||
that were committed as of the query start time. However, such a target
|
that were committed as of the query start time. However, such a target
|
||||||
@ -287,9 +285,9 @@ COMMIT;
|
|||||||
be necessary to guarantee a more rigorously consistent view of the
|
be necessary to guarantee a more rigorously consistent view of the
|
||||||
database than the Read Committed mode provides.
|
database than the Read Committed mode provides.
|
||||||
</para>
|
</para>
|
||||||
</sect1>
|
</sect2>
|
||||||
|
|
||||||
<sect1 id="xact-serializable">
|
<sect2 id="xact-serializable">
|
||||||
<title>Serializable Isolation Level</title>
|
<title>Serializable Isolation Level</title>
|
||||||
|
|
||||||
<indexterm>
|
<indexterm>
|
||||||
@ -316,13 +314,13 @@ COMMIT;
|
|||||||
committed.) This is different from Read Committed in that the
|
committed.) This is different from Read Committed in that the
|
||||||
<command>SELECT</command>
|
<command>SELECT</command>
|
||||||
sees a snapshot as of the start of the transaction, not as of the start
|
sees a snapshot as of the start of the transaction, not as of the start
|
||||||
of the current query within the transaction. Successive
|
of the current query within the transaction. Thus, successive
|
||||||
<command>SELECT</command>s within a single transaction always see the same
|
<command>SELECT</command>s within a single transaction always see the same
|
||||||
data.
|
data.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
<command>UPDATE</command>, <command>DELETE</command> and <command>SELECT
|
<command>UPDATE</command>, <command>DELETE</command>, and <command>SELECT
|
||||||
FOR UPDATE</command> commands behave the same as <command>SELECT</command>
|
FOR UPDATE</command> commands behave the same as <command>SELECT</command>
|
||||||
in terms of searching for target rows: they will only find target rows
|
in terms of searching for target rows: they will only find target rows
|
||||||
that were committed as of the transaction start time. However, such a
|
that were committed as of the transaction start time. However, such a
|
||||||
@ -370,6 +368,7 @@ ERROR: Can't serialize access due to concurrent update
|
|||||||
a transaction performs several successive queries that must see
|
a transaction performs several successive queries that must see
|
||||||
identical views of the database.
|
identical views of the database.
|
||||||
</para>
|
</para>
|
||||||
|
</sect2>
|
||||||
</sect1>
|
</sect1>
|
||||||
|
|
||||||
<sect1 id="explicit-locking">
|
<sect1 id="explicit-locking">
|
||||||
@ -421,8 +420,7 @@ ERROR: Can't serialize access due to concurrent update
|
|||||||
To examine a list of the currently outstanding locks in a
|
To examine a list of the currently outstanding locks in a
|
||||||
database server, use the <literal>pg_locks</literal> system
|
database server, use the <literal>pg_locks</literal> system
|
||||||
view. For more information on monitoring the status of the lock
|
view. For more information on monitoring the status of the lock
|
||||||
manager subsystem, refer to the <citetitle>Administrator's
|
manager subsystem, refer to the &cite-admin;.
|
||||||
Guide</citetitle>.
|
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<variablelist>
|
<variablelist>
|
||||||
@ -647,14 +645,14 @@ ERROR: Can't serialize access due to concurrent update
|
|||||||
<para>
|
<para>
|
||||||
Use of explicit locking can cause <firstterm>deadlocks</>, wherein
|
Use of explicit locking can cause <firstterm>deadlocks</>, wherein
|
||||||
two (or more) transactions each hold locks that the other wants.
|
two (or more) transactions each hold locks that the other wants.
|
||||||
For example, if transaction 1 acquires exclusive lock on table A
|
For example, if transaction 1 acquires an exclusive lock on table A
|
||||||
and then tries to acquire exclusive lock on table B, while transaction
|
and then tries to acquire an exclusive lock on table B, while transaction
|
||||||
2 has already exclusive-locked table B and now wants exclusive lock
|
2 has already exclusive-locked table B and now wants an exclusive lock
|
||||||
on table A, then neither one can proceed.
|
on table A, then neither one can proceed.
|
||||||
<productname>PostgreSQL</productname> automatically detects deadlock
|
<productname>PostgreSQL</productname> automatically detects deadlock
|
||||||
situations and resolves them by aborting one of the transactions
|
situations and resolves them by aborting one of the transactions
|
||||||
involved, allowing the other(s) to complete. (Exactly which transaction
|
involved, allowing the other(s) to complete. (Exactly which transaction
|
||||||
will be aborted is difficult to predict, and should not be relied on.)
|
will be aborted is difficult to predict and should not be relied on.)
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
@ -678,7 +676,7 @@ ERROR: Can't serialize access due to concurrent update
|
|||||||
</sect1>
|
</sect1>
|
||||||
|
|
||||||
<sect1 id="applevel-consistency">
|
<sect1 id="applevel-consistency">
|
||||||
<title>Data consistency checks at the application level</title>
|
<title>Data Consistency Checks at the Application Level</title>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
Because readers in <productname>PostgreSQL</productname>
|
Because readers in <productname>PostgreSQL</productname>
|
||||||
@ -718,11 +716,10 @@ ERROR: Can't serialize access due to concurrent update
|
|||||||
|
|
||||||
<note>
|
<note>
|
||||||
<para>
|
<para>
|
||||||
Before version 6.5 <productname>PostgreSQL</productname>
|
Before version 6.5 <productname>PostgreSQL</productname> used
|
||||||
used read-locks and so the
|
read locks, and so the above consideration is also the case when
|
||||||
above consideration is also the case
|
upgrading from <productname>PostgreSQL</productname> versions
|
||||||
when upgrading to 6.5 (or higher) from previous
|
prior to 6.5.
|
||||||
<productname>PostgreSQL</productname> versions.
|
|
||||||
</para>
|
</para>
|
||||||
</note>
|
</note>
|
||||||
</para>
|
</para>
|
||||||
@ -732,7 +729,7 @@ ERROR: Can't serialize access due to concurrent update
|
|||||||
example, a banking application might wish to check that the sum of
|
example, a banking application might wish to check that the sum of
|
||||||
all credits in one table equals the sum of debits in another table,
|
all credits in one table equals the sum of debits in another table,
|
||||||
when both tables are being actively updated. Comparing the results of two
|
when both tables are being actively updated. Comparing the results of two
|
||||||
successive SELECT SUM(...) commands will not work reliably under
|
successive <literal>SELECT SUM(...)</literal> commands will not work reliably under
|
||||||
Read Committed mode, since the second query will likely include the results
|
Read Committed mode, since the second query will likely include the results
|
||||||
of transactions not counted by the first. Doing the two sums in a
|
of transactions not counted by the first. Doing the two sums in a
|
||||||
single serializable transaction will give an accurate picture of the
|
single serializable transaction will give an accurate picture of the
|
||||||
@ -758,7 +755,8 @@ ERROR: Can't serialize access due to concurrent update
|
|||||||
the table are still running --- but if the snapshot seen by the
|
the table are still running --- but if the snapshot seen by the
|
||||||
transaction predates obtaining the lock, it may predate some now-committed
|
transaction predates obtaining the lock, it may predate some now-committed
|
||||||
changes in the table. A serializable transaction's snapshot is actually
|
changes in the table. A serializable transaction's snapshot is actually
|
||||||
frozen at the start of its first query (SELECT/INSERT/UPDATE/DELETE), so
|
frozen at the start of its first query (<literal>SELECT</>, <literal>INSERT</>,
|
||||||
|
<literal>UPDATE</>, or <literal>DELETE</>), so
|
||||||
it's possible to obtain explicit locks before the snapshot is
|
it's possible to obtain explicit locks before the snapshot is
|
||||||
frozen.
|
frozen.
|
||||||
</para>
|
</para>
|
||||||
@ -781,12 +779,26 @@ ERROR: Can't serialize access due to concurrent update
|
|||||||
<variablelist>
|
<variablelist>
|
||||||
<varlistentry>
|
<varlistentry>
|
||||||
<term>
|
<term>
|
||||||
<acronym>GiST</acronym> and R-Tree indexes
|
B-tree indexes
|
||||||
|
</term>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
Short-term share/exclusive page-level locks are used for
|
||||||
|
read/write access. Locks are released immediately after each
|
||||||
|
index tuple is fetched or inserted. B-tree indexes provide
|
||||||
|
the highest concurrency without deadlock conditions.
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
</varlistentry>
|
||||||
|
|
||||||
|
<varlistentry>
|
||||||
|
<term>
|
||||||
|
<acronym>GiST</acronym> and R-tree indexes
|
||||||
</term>
|
</term>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
Share/exclusive index-level locks are used for read/write access.
|
Share/exclusive index-level locks are used for read/write access.
|
||||||
Locks are released after statement is done.
|
Locks are released after the statement (command) is done.
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
@ -797,31 +809,10 @@ ERROR: Can't serialize access due to concurrent update
|
|||||||
</term>
|
</term>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
Share/exclusive page-level locks are used for read/write access.
|
Share/exclusive page-level locks are used for read/write
|
||||||
Locks are released after page is processed.
|
access. Locks are released after the page is processed.
|
||||||
</para>
|
Page-level locks provide better concurrency than index-level
|
||||||
|
ones but are liable to deadlocks.
|
||||||
<para>
|
|
||||||
Page-level locks provide better concurrency than index-level ones
|
|
||||||
but are subject to deadlocks.
|
|
||||||
</para>
|
|
||||||
</listitem>
|
|
||||||
</varlistentry>
|
|
||||||
|
|
||||||
<varlistentry>
|
|
||||||
<term>
|
|
||||||
B-tree indexes
|
|
||||||
</term>
|
|
||||||
<listitem>
|
|
||||||
<para>
|
|
||||||
Short-term share/exclusive page-level locks are used for
|
|
||||||
read/write access. Locks are released immediately after each index
|
|
||||||
tuple is fetched/inserted.
|
|
||||||
</para>
|
|
||||||
|
|
||||||
<para>
|
|
||||||
B-tree indexes provide the highest concurrency without deadlock
|
|
||||||
conditions.
|
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
|
@ -1,5 +1,5 @@
|
|||||||
<!--
|
<!--
|
||||||
$Header: /cvsroot/pgsql/doc/src/sgml/perform.sgml,v 1.21 2002/09/21 18:32:53 petere Exp $
|
$Header: /cvsroot/pgsql/doc/src/sgml/perform.sgml,v 1.22 2002/11/11 20:14:03 petere Exp $
|
||||||
-->
|
-->
|
||||||
|
|
||||||
<chapter id="performance-tips">
|
<chapter id="performance-tips">
|
||||||
@ -32,30 +32,30 @@ $Header: /cvsroot/pgsql/doc/src/sgml/perform.sgml,v 1.21 2002/09/21 18:32:53 pet
|
|||||||
<itemizedlist>
|
<itemizedlist>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
Estimated start-up cost (time expended before output scan can start,
|
Estimated start-up cost (Time expended before output scan can start,
|
||||||
e.g., time to do the sorting in a SORT node).
|
e.g., time to do the sorting in a sort node.)
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
Estimated total cost (if all tuples are retrieved, which they may not
|
Estimated total cost (If all rows are retrieved, which they may not
|
||||||
be --- a query with a LIMIT will stop short of paying the total cost,
|
be --- a query with a <literal>LIMIT</> clause will stop short of paying the total cost,
|
||||||
for example).
|
for example.)
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
Estimated number of rows output by this plan node (again, only if
|
Estimated number of rows output by this plan node (Again, only if
|
||||||
executed to completion).
|
executed to completion.)
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
Estimated average width (in bytes) of rows output by this plan
|
Estimated average width (in bytes) of rows output by this plan
|
||||||
node.
|
node
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</itemizedlist>
|
</itemizedlist>
|
||||||
@ -64,9 +64,9 @@ $Header: /cvsroot/pgsql/doc/src/sgml/perform.sgml,v 1.21 2002/09/21 18:32:53 pet
|
|||||||
<para>
|
<para>
|
||||||
The costs are measured in units of disk page fetches. (CPU effort
|
The costs are measured in units of disk page fetches. (CPU effort
|
||||||
estimates are converted into disk-page units using some
|
estimates are converted into disk-page units using some
|
||||||
fairly arbitrary fudge-factors. If you want to experiment with these
|
fairly arbitrary fudge factors. If you want to experiment with these
|
||||||
factors, see the list of run-time configuration parameters in the
|
factors, see the list of run-time configuration parameters in the
|
||||||
<citetitle>Administrator's Guide</citetitle>.)
|
&cite-admin;.)
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
@ -74,17 +74,17 @@ $Header: /cvsroot/pgsql/doc/src/sgml/perform.sgml,v 1.21 2002/09/21 18:32:53 pet
|
|||||||
the cost of all its child nodes. It's also important to realize that
|
the cost of all its child nodes. It's also important to realize that
|
||||||
the cost only reflects things that the planner/optimizer cares about.
|
the cost only reflects things that the planner/optimizer cares about.
|
||||||
In particular, the cost does not consider the time spent transmitting
|
In particular, the cost does not consider the time spent transmitting
|
||||||
result tuples to the frontend --- which could be a pretty dominant
|
result rows to the frontend --- which could be a pretty dominant
|
||||||
factor in the true elapsed time, but the planner ignores it because
|
factor in the true elapsed time, but the planner ignores it because
|
||||||
it cannot change it by altering the plan. (Every correct plan will
|
it cannot change it by altering the plan. (Every correct plan will
|
||||||
output the same tuple set, we trust.)
|
output the same row set, we trust.)
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
Rows output is a little tricky because it is <emphasis>not</emphasis> the
|
Rows output is a little tricky because it is <emphasis>not</emphasis> the
|
||||||
number of rows
|
number of rows
|
||||||
processed/scanned by the query --- it is usually less, reflecting the
|
processed/scanned by the query --- it is usually less, reflecting the
|
||||||
estimated selectivity of any WHERE-clause constraints that are being
|
estimated selectivity of any <literal>WHERE</>-clause constraints that are being
|
||||||
applied at this node. Ideally the top-level rows estimate will
|
applied at this node. Ideally the top-level rows estimate will
|
||||||
approximate the number of rows actually returned, updated, or deleted
|
approximate the number of rows actually returned, updated, or deleted
|
||||||
by the query.
|
by the query.
|
||||||
@ -92,44 +92,44 @@ $Header: /cvsroot/pgsql/doc/src/sgml/perform.sgml,v 1.21 2002/09/21 18:32:53 pet
|
|||||||
|
|
||||||
<para>
|
<para>
|
||||||
Here are some examples (using the regress test database after a
|
Here are some examples (using the regress test database after a
|
||||||
vacuum analyze, and 7.3 development sources):
|
<literal>VACUUM ANALYZE</>, and 7.3 development sources):
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
regression=# EXPLAIN SELECT * FROM tenk1;
|
regression=# EXPLAIN SELECT * FROM tenk1;
|
||||||
QUERY PLAN
|
QUERY PLAN
|
||||||
-------------------------------------------------------------
|
-------------------------------------------------------------
|
||||||
Seq Scan on tenk1 (cost=0.00..333.00 rows=10000 width=148)
|
Seq Scan on tenk1 (cost=0.00..333.00 rows=10000 width=148)
|
||||||
</programlisting>
|
</programlisting>
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
This is about as straightforward as it gets. If you do
|
This is about as straightforward as it gets. If you do
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
SELECT * FROM pg_class WHERE relname = 'tenk1';
|
SELECT * FROM pg_class WHERE relname = 'tenk1';
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
|
||||||
you will find out that <classname>tenk1</classname> has 233 disk
|
you will find out that <classname>tenk1</classname> has 233 disk
|
||||||
pages and 10000 tuples. So the cost is estimated at 233 page
|
pages and 10000 rows. So the cost is estimated at 233 page
|
||||||
reads, defined as 1.0 apiece, plus 10000 * <varname>cpu_tuple_cost</varname> which is
|
reads, defined as costing 1.0 apiece, plus 10000 * <varname>cpu_tuple_cost</varname> which is
|
||||||
currently 0.01 (try <command>show cpu_tuple_cost</command>).
|
currently 0.01 (try <command>SHOW cpu_tuple_cost</command>).
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
Now let's modify the query to add a WHERE condition:
|
Now let's modify the query to add a <literal>WHERE</> condition:
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
regression=# EXPLAIN SELECT * FROM tenk1 WHERE unique1 < 1000;
|
regression=# EXPLAIN SELECT * FROM tenk1 WHERE unique1 < 1000;
|
||||||
QUERY PLAN
|
QUERY PLAN
|
||||||
------------------------------------------------------------
|
------------------------------------------------------------
|
||||||
Seq Scan on tenk1 (cost=0.00..358.00 rows=1033 width=148)
|
Seq Scan on tenk1 (cost=0.00..358.00 rows=1033 width=148)
|
||||||
Filter: (unique1 < 1000)
|
Filter: (unique1 < 1000)
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
|
||||||
The estimate of output rows has gone down because of the WHERE clause.
|
The estimate of output rows has gone down because of the <literal>WHERE</> clause.
|
||||||
However, the scan will still have to visit all 10000 rows, so the cost
|
However, the scan will still have to visit all 10000 rows, so the cost
|
||||||
hasn't decreased; in fact it has gone up a bit to reflect the extra CPU
|
hasn't decreased; in fact it has gone up a bit to reflect the extra CPU
|
||||||
time spent checking the WHERE condition.
|
time spent checking the <literal>WHERE</> condition.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
@ -144,26 +144,26 @@ regression=# EXPLAIN SELECT * FROM tenk1 WHERE unique1 < 1000;
|
|||||||
<para>
|
<para>
|
||||||
Modify the query to restrict the condition even more:
|
Modify the query to restrict the condition even more:
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
regression=# EXPLAIN SELECT * FROM tenk1 WHERE unique1 < 50;
|
regression=# EXPLAIN SELECT * FROM tenk1 WHERE unique1 < 50;
|
||||||
QUERY PLAN
|
QUERY PLAN
|
||||||
-------------------------------------------------------------------------------
|
-------------------------------------------------------------------------------
|
||||||
Index Scan using tenk1_unique1 on tenk1 (cost=0.00..179.33 rows=49 width=148)
|
Index Scan using tenk1_unique1 on tenk1 (cost=0.00..179.33 rows=49 width=148)
|
||||||
Index Cond: (unique1 < 50)
|
Index Cond: (unique1 < 50)
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
|
||||||
and you will see that if we make the WHERE condition selective
|
and you will see that if we make the <literal>WHERE</> condition selective
|
||||||
enough, the planner will
|
enough, the planner will
|
||||||
eventually decide that an index scan is cheaper than a sequential scan.
|
eventually decide that an index scan is cheaper than a sequential scan.
|
||||||
This plan will only have to visit 50 tuples because of the index,
|
This plan will only have to visit 50 rows because of the index,
|
||||||
so it wins despite the fact that each individual fetch is more expensive
|
so it wins despite the fact that each individual fetch is more expensive
|
||||||
than reading a whole disk page sequentially.
|
than reading a whole disk page sequentially.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
Add another clause to the WHERE condition:
|
Add another clause to the <literal>WHERE</> condition:
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
regression=# EXPLAIN SELECT * FROM tenk1 WHERE unique1 < 50 AND
|
regression=# EXPLAIN SELECT * FROM tenk1 WHERE unique1 < 50 AND
|
||||||
regression-# stringu1 = 'xxx';
|
regression-# stringu1 = 'xxx';
|
||||||
QUERY PLAN
|
QUERY PLAN
|
||||||
@ -171,11 +171,11 @@ regression-# stringu1 = 'xxx';
|
|||||||
Index Scan using tenk1_unique1 on tenk1 (cost=0.00..179.45 rows=1 width=148)
|
Index Scan using tenk1_unique1 on tenk1 (cost=0.00..179.45 rows=1 width=148)
|
||||||
Index Cond: (unique1 < 50)
|
Index Cond: (unique1 < 50)
|
||||||
Filter: (stringu1 = 'xxx'::name)
|
Filter: (stringu1 = 'xxx'::name)
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
|
||||||
The added clause <literal>stringu1 = 'xxx'</literal> reduces the
|
The added clause <literal>stringu1 = 'xxx'</literal> reduces the
|
||||||
output-rows estimate, but not the cost because we still have to visit the
|
output-rows estimate, but not the cost because we still have to visit the
|
||||||
same set of tuples. Notice that the <literal>stringu1</> clause
|
same set of rows. Notice that the <literal>stringu1</> clause
|
||||||
cannot be applied as an index condition (since this index is only on
|
cannot be applied as an index condition (since this index is only on
|
||||||
the <literal>unique1</> column). Instead it is applied as a filter on
|
the <literal>unique1</> column). Instead it is applied as a filter on
|
||||||
the rows retrieved by the index. Thus the cost has actually gone up
|
the rows retrieved by the index. Thus the cost has actually gone up
|
||||||
@ -185,7 +185,7 @@ regression-# stringu1 = 'xxx';
|
|||||||
<para>
|
<para>
|
||||||
Let's try joining two tables, using the fields we have been discussing:
|
Let's try joining two tables, using the fields we have been discussing:
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
regression=# EXPLAIN SELECT * FROM tenk1 t1, tenk2 t2 WHERE t1.unique1 < 50
|
regression=# EXPLAIN SELECT * FROM tenk1 t1, tenk2 t2 WHERE t1.unique1 < 50
|
||||||
regression-# AND t1.unique2 = t2.unique2;
|
regression-# AND t1.unique2 = t2.unique2;
|
||||||
QUERY PLAN
|
QUERY PLAN
|
||||||
@ -197,30 +197,30 @@ regression-# AND t1.unique2 = t2.unique2;
|
|||||||
-> Index Scan using tenk2_unique2 on tenk2 t2
|
-> Index Scan using tenk2_unique2 on tenk2 t2
|
||||||
(cost=0.00..3.01 rows=1 width=148)
|
(cost=0.00..3.01 rows=1 width=148)
|
||||||
Index Cond: ("outer".unique2 = t2.unique2)
|
Index Cond: ("outer".unique2 = t2.unique2)
|
||||||
</programlisting>
|
</programlisting>
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
In this nested-loop join, the outer scan is the same index scan we had
|
In this nested-loop join, the outer scan is the same index scan we had
|
||||||
in the example before last, and so its cost and row count are the same
|
in the example before last, and so its cost and row count are the same
|
||||||
because we are applying the <literal>unique1 < 50</literal> WHERE clause at that node.
|
because we are applying the <literal>unique1 < 50</literal> <literal>WHERE</> clause at that node.
|
||||||
The <literal>t1.unique2 = t2.unique2</literal> clause is not relevant yet, so it doesn't
|
The <literal>t1.unique2 = t2.unique2</literal> clause is not relevant yet, so it doesn't
|
||||||
affect row count of the outer scan. For the inner scan, the unique2 value of the
|
affect row count of the outer scan. For the inner scan, the <literal>unique2</> value of the
|
||||||
current
|
current
|
||||||
outer-scan tuple is plugged into the inner index scan
|
outer-scan row is plugged into the inner index scan
|
||||||
to produce an index condition like
|
to produce an index condition like
|
||||||
<literal>t2.unique2 = <replaceable>constant</replaceable></literal>. So we get the
|
<literal>t2.unique2 = <replaceable>constant</replaceable></literal>. So we get the
|
||||||
same inner-scan plan and costs that we'd get from, say, <literal>explain select
|
same inner-scan plan and costs that we'd get from, say, <literal>EXPLAIN SELECT
|
||||||
* from tenk2 where unique2 = 42</literal>. The costs of the loop node are then set
|
* FROM tenk2 WHERE unique2 = 42</literal>. The costs of the loop node are then set
|
||||||
on the basis of the cost of the outer scan, plus one repetition of the
|
on the basis of the cost of the outer scan, plus one repetition of the
|
||||||
inner scan for each outer tuple (49 * 3.01, here), plus a little CPU
|
inner scan for each outer row (49 * 3.01, here), plus a little CPU
|
||||||
time for join processing.
|
time for join processing.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
In this example the loop's output row count is the same as the product
|
In this example the loop's output row count is the same as the product
|
||||||
of the two scans' row counts, but that's not true in general, because
|
of the two scans' row counts, but that's not true in general, because
|
||||||
in general you can have WHERE clauses that mention both relations and
|
in general you can have <literal>WHERE</> clauses that mention both relations and
|
||||||
so can only be applied at the join point, not to either input scan.
|
so can only be applied at the join point, not to either input scan.
|
||||||
For example, if we added <literal>WHERE ... AND t1.hundred < t2.hundred</literal>,
|
For example, if we added <literal>WHERE ... AND t1.hundred < t2.hundred</literal>,
|
||||||
that would decrease the output row count of the join node, but not change
|
that would decrease the output row count of the join node, but not change
|
||||||
@ -233,9 +233,9 @@ regression-# AND t1.unique2 = t2.unique2;
|
|||||||
flags for each plan type. (This is a crude tool, but useful. See
|
flags for each plan type. (This is a crude tool, but useful. See
|
||||||
also <xref linkend="explicit-joins">.)
|
also <xref linkend="explicit-joins">.)
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
regression=# set enable_nestloop = off;
|
regression=# SET enable_nestloop = off;
|
||||||
SET VARIABLE
|
SET
|
||||||
regression=# EXPLAIN SELECT * FROM tenk1 t1, tenk2 t2 WHERE t1.unique1 < 50
|
regression=# EXPLAIN SELECT * FROM tenk1 t1, tenk2 t2 WHERE t1.unique1 < 50
|
||||||
regression-# AND t1.unique2 = t2.unique2;
|
regression-# AND t1.unique2 = t2.unique2;
|
||||||
QUERY PLAN
|
QUERY PLAN
|
||||||
@ -247,25 +247,25 @@ regression-# AND t1.unique2 = t2.unique2;
|
|||||||
-> Index Scan using tenk1_unique1 on tenk1 t1
|
-> Index Scan using tenk1_unique1 on tenk1 t1
|
||||||
(cost=0.00..179.33 rows=49 width=148)
|
(cost=0.00..179.33 rows=49 width=148)
|
||||||
Index Cond: (unique1 < 50)
|
Index Cond: (unique1 < 50)
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
|
||||||
This plan proposes to extract the 50 interesting rows of <classname>tenk1</classname>
|
This plan proposes to extract the 50 interesting rows of <classname>tenk1</classname>
|
||||||
using ye same olde index scan, stash them into an in-memory hash table,
|
using ye same olde index scan, stash them into an in-memory hash table,
|
||||||
and then do a sequential scan of <classname>tenk2</classname>, probing into the hash table
|
and then do a sequential scan of <classname>tenk2</classname>, probing into the hash table
|
||||||
for possible matches of <literal>t1.unique2 = t2.unique2</literal> at each <classname>tenk2</classname> tuple.
|
for possible matches of <literal>t1.unique2 = t2.unique2</literal> at each <classname>tenk2</classname> row.
|
||||||
The cost to read <classname>tenk1</classname> and set up the hash table is entirely start-up
|
The cost to read <classname>tenk1</classname> and set up the hash table is entirely start-up
|
||||||
cost for the hash join, since we won't get any tuples out until we can
|
cost for the hash join, since we won't get any rows out until we can
|
||||||
start reading <classname>tenk2</classname>. The total time estimate for the join also
|
start reading <classname>tenk2</classname>. The total time estimate for the join also
|
||||||
includes a hefty charge for CPU time to probe the hash table
|
includes a hefty charge for the CPU time to probe the hash table
|
||||||
10000 times. Note, however, that we are NOT charging 10000 times 179.33;
|
10000 times. Note, however, that we are <emphasis>not</emphasis> charging 10000 times 179.33;
|
||||||
the hash table setup is only done once in this plan type.
|
the hash table setup is only done once in this plan type.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
It is possible to check on the accuracy of the planner's estimated costs
|
It is possible to check on the accuracy of the planner's estimated costs
|
||||||
by using EXPLAIN ANALYZE. This command actually executes the query,
|
by using <command>EXPLAIN ANALYZE</>. This command actually executes the query,
|
||||||
and then displays the true run time accumulated within each plan node
|
and then displays the true run time accumulated within each plan node
|
||||||
along with the same estimated costs that a plain EXPLAIN shows.
|
along with the same estimated costs that a plain <command>EXPLAIN</command> shows.
|
||||||
For example, we might get a result like this:
|
For example, we might get a result like this:
|
||||||
|
|
||||||
<screen>
|
<screen>
|
||||||
@ -296,7 +296,7 @@ regression-# WHERE t1.unique1 < 50 AND t1.unique2 = t2.unique2;
|
|||||||
<para>
|
<para>
|
||||||
In some query plans, it is possible for a subplan node to be executed more
|
In some query plans, it is possible for a subplan node to be executed more
|
||||||
than once. For example, the inner index scan is executed once per outer
|
than once. For example, the inner index scan is executed once per outer
|
||||||
tuple in the above nested-loop plan. In such cases, the
|
row in the above nested-loop plan. In such cases, the
|
||||||
<quote>loops</quote> value reports the
|
<quote>loops</quote> value reports the
|
||||||
total number of executions of the node, and the actual time and rows
|
total number of executions of the node, and the actual time and rows
|
||||||
values shown are averages per-execution. This is done to make the numbers
|
values shown are averages per-execution. This is done to make the numbers
|
||||||
@ -307,19 +307,19 @@ regression-# WHERE t1.unique1 < 50 AND t1.unique2 = t2.unique2;
|
|||||||
|
|
||||||
<para>
|
<para>
|
||||||
The <literal>Total runtime</literal> shown by <command>EXPLAIN ANALYZE</command> includes
|
The <literal>Total runtime</literal> shown by <command>EXPLAIN ANALYZE</command> includes
|
||||||
executor start-up and shutdown time, as well as time spent processing
|
executor start-up and shut-down time, as well as time spent processing
|
||||||
the result tuples. It does not include parsing, rewriting, or planning
|
the result rows. It does not include parsing, rewriting, or planning
|
||||||
time. For a SELECT query, the total run time will normally be just a
|
time. For a <command>SELECT</> query, the total run time will normally be just a
|
||||||
little larger than the total time reported for the top-level plan node.
|
little larger than the total time reported for the top-level plan node.
|
||||||
For INSERT, UPDATE, and DELETE queries, the total run time may be
|
For <command>INSERT</>, <command>UPDATE</>, and <command>DELETE</> commands, the total run time may be
|
||||||
considerably larger, because it includes the time spent processing the
|
considerably larger, because it includes the time spent processing the
|
||||||
result tuples. In these queries, the time for the top plan node
|
result rows. In these commands, the time for the top plan node
|
||||||
essentially is the time spent computing the new tuples and/or locating
|
essentially is the time spent computing the new rows and/or locating
|
||||||
the old ones, but it doesn't include the time spent making the changes.
|
the old ones, but it doesn't include the time spent making the changes.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
It is worth noting that EXPLAIN results should not be extrapolated
|
It is worth noting that <command>EXPLAIN</> results should not be extrapolated
|
||||||
to situations other than the one you are actually testing; for example,
|
to situations other than the one you are actually testing; for example,
|
||||||
results on a toy-sized table can't be assumed to apply to large tables.
|
results on a toy-sized table can't be assumed to apply to large tables.
|
||||||
The planner's cost estimates are not linear and so it may well choose
|
The planner's cost estimates are not linear and so it may well choose
|
||||||
@ -333,7 +333,7 @@ regression-# WHERE t1.unique1 < 50 AND t1.unique2 = t2.unique2;
|
|||||||
</sect1>
|
</sect1>
|
||||||
|
|
||||||
<sect1 id="planner-stats">
|
<sect1 id="planner-stats">
|
||||||
<title>Statistics used by the Planner</title>
|
<title>Statistics Used by the Planner</title>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
As we saw in the previous section, the query planner needs to estimate
|
As we saw in the previous section, the query planner needs to estimate
|
||||||
@ -351,8 +351,8 @@ regression-# WHERE t1.unique1 < 50 AND t1.unique2 = t2.unique2;
|
|||||||
with queries similar to this one:
|
with queries similar to this one:
|
||||||
|
|
||||||
<screen>
|
<screen>
|
||||||
regression=# select relname, relkind, reltuples, relpages from pg_class
|
regression=# SELECT relname, relkind, reltuples, relpages FROM pg_class
|
||||||
regression-# where relname like 'tenk1%';
|
regression-# WHERE relname LIKE 'tenk1%';
|
||||||
relname | relkind | reltuples | relpages
|
relname | relkind | reltuples | relpages
|
||||||
---------------+---------+-----------+----------
|
---------------+---------+-----------+----------
|
||||||
tenk1 | r | 10000 | 233
|
tenk1 | r | 10000 | 233
|
||||||
@ -382,10 +382,10 @@ regression-# where relname like 'tenk1%';
|
|||||||
|
|
||||||
<para>
|
<para>
|
||||||
Most queries retrieve only a fraction of the rows in a table, due
|
Most queries retrieve only a fraction of the rows in a table, due
|
||||||
to having WHERE clauses that restrict the rows to be examined.
|
to having <literal>WHERE</> clauses that restrict the rows to be examined.
|
||||||
The planner thus needs to make an estimate of the
|
The planner thus needs to make an estimate of the
|
||||||
<firstterm>selectivity</> of WHERE clauses, that is, the fraction of
|
<firstterm>selectivity</> of <literal>WHERE</> clauses, that is, the fraction of
|
||||||
rows that match each clause of the WHERE condition. The information
|
rows that match each clause of the <literal>WHERE</> condition. The information
|
||||||
used for this task is stored in the <structname>pg_statistic</structname>
|
used for this task is stored in the <structname>pg_statistic</structname>
|
||||||
system catalog. Entries in <structname>pg_statistic</structname> are
|
system catalog. Entries in <structname>pg_statistic</structname> are
|
||||||
updated by <command>ANALYZE</> and <command>VACUUM ANALYZE</> commands,
|
updated by <command>ANALYZE</> and <command>VACUUM ANALYZE</> commands,
|
||||||
@ -406,7 +406,7 @@ regression-# where relname like 'tenk1%';
|
|||||||
For example, we might do:
|
For example, we might do:
|
||||||
|
|
||||||
<screen>
|
<screen>
|
||||||
regression=# select attname, n_distinct, most_common_vals from pg_stats where tablename = 'road';
|
regression=# SELECT attname, n_distinct, most_common_vals FROM pg_stats WHERE tablename = 'road';
|
||||||
attname | n_distinct | most_common_vals
|
attname | n_distinct | most_common_vals
|
||||||
---------+------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|
---------+------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||||
name | -0.467008 | {"I- 580 Ramp","I- 880 Ramp","Sp Railroad ","I- 580 ","I- 680 Ramp","I- 80 Ramp","14th St ","5th St ","Mission Blvd","I- 880 "}
|
name | -0.467008 | {"I- 580 Ramp","I- 880 Ramp","Sp Railroad ","I- 580 ","I- 680 Ramp","I- 80 Ramp","14th St ","5th St ","Mission Blvd","I- 880 "}
|
||||||
@ -414,12 +414,14 @@ regression=# select attname, n_distinct, most_common_vals from pg_stats where ta
|
|||||||
(2 rows)
|
(2 rows)
|
||||||
regression=#
|
regression=#
|
||||||
</screen>
|
</screen>
|
||||||
|
|
||||||
As of <productname>PostgreSQL</productname> 7.2 the following columns exist
|
|
||||||
in <structname>pg_stats</structname>:
|
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<table>
|
<para>
|
||||||
|
<xref linkend="planner-pg-stats-table"> shows the columns that
|
||||||
|
exist in <structname>pg_stats</structname>.
|
||||||
|
</para>
|
||||||
|
|
||||||
|
<table id="planner-pg-stats-table">
|
||||||
<title><structname>pg_stats</structname> Columns</title>
|
<title><structname>pg_stats</structname> Columns</title>
|
||||||
|
|
||||||
<tgroup cols=3>
|
<tgroup cols=3>
|
||||||
@ -435,7 +437,7 @@ regression=#
|
|||||||
<row>
|
<row>
|
||||||
<entry><literal>tablename</literal></entry>
|
<entry><literal>tablename</literal></entry>
|
||||||
<entry><type>name</type></entry>
|
<entry><type>name</type></entry>
|
||||||
<entry>Name of table containing column</entry>
|
<entry>Name of the table containing the column</entry>
|
||||||
</row>
|
</row>
|
||||||
|
|
||||||
<row>
|
<row>
|
||||||
@ -447,13 +449,13 @@ regression=#
|
|||||||
<row>
|
<row>
|
||||||
<entry><literal>null_frac</literal></entry>
|
<entry><literal>null_frac</literal></entry>
|
||||||
<entry><type>real</type></entry>
|
<entry><type>real</type></entry>
|
||||||
<entry>Fraction of column's entries that are NULL</entry>
|
<entry>Fraction of column's entries that are null</entry>
|
||||||
</row>
|
</row>
|
||||||
|
|
||||||
<row>
|
<row>
|
||||||
<entry><literal>avg_width</literal></entry>
|
<entry><literal>avg_width</literal></entry>
|
||||||
<entry><type>integer</type></entry>
|
<entry><type>integer</type></entry>
|
||||||
<entry>Average width in bytes of column's entries</entry>
|
<entry>Average width in bytes of the column's entries</entry>
|
||||||
</row>
|
</row>
|
||||||
|
|
||||||
<row>
|
<row>
|
||||||
@ -462,7 +464,7 @@ regression=#
|
|||||||
<entry>If greater than zero, the estimated number of distinct values
|
<entry>If greater than zero, the estimated number of distinct values
|
||||||
in the column. If less than zero, the negative of the number of
|
in the column. If less than zero, the negative of the number of
|
||||||
distinct values divided by the number of rows. (The negated form
|
distinct values divided by the number of rows. (The negated form
|
||||||
is used when ANALYZE believes that the number of distinct values
|
is used when <command>ANALYZE</> believes that the number of distinct values
|
||||||
is likely to increase as the table grows; the positive form is used
|
is likely to increase as the table grows; the positive form is used
|
||||||
when the column seems to have a fixed number of possible values.)
|
when the column seems to have a fixed number of possible values.)
|
||||||
For example, -1 indicates a unique column in which the number of
|
For example, -1 indicates a unique column in which the number of
|
||||||
@ -481,7 +483,7 @@ regression=#
|
|||||||
<entry><literal>most_common_freqs</literal></entry>
|
<entry><literal>most_common_freqs</literal></entry>
|
||||||
<entry><type>real[]</type></entry>
|
<entry><type>real[]</type></entry>
|
||||||
<entry>A list of the frequencies of the most common values,
|
<entry>A list of the frequencies of the most common values,
|
||||||
ie, number of occurrences of each divided by total number of rows.
|
i.e., number of occurrences of each divided by total number of rows.
|
||||||
</entry>
|
</entry>
|
||||||
</row>
|
</row>
|
||||||
|
|
||||||
@ -530,30 +532,32 @@ regression=#
|
|||||||
<title>Controlling the Planner with Explicit <literal>JOIN</> Clauses</title>
|
<title>Controlling the Planner with Explicit <literal>JOIN</> Clauses</title>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
Beginning with <productname>PostgreSQL</productname> 7.1 it is possible
|
Beginning with <productname>PostgreSQL</productname> 7.1 it has been possible
|
||||||
to control the query planner to some extent by using explicit <literal>JOIN</>
|
to control the query planner to some extent by using the explicit <literal>JOIN</>
|
||||||
syntax. To see why this matters, we first need some background.
|
syntax. To see why this matters, we first need some background.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
In a simple join query, such as
|
In a simple join query, such as
|
||||||
<programlisting>
|
<programlisting>
|
||||||
SELECT * FROM a,b,c WHERE a.id = b.id AND b.ref = c.id;
|
SELECT * FROM a, b, c WHERE a.id = b.id AND b.ref = c.id;
|
||||||
</programlisting>
|
</programlisting>
|
||||||
the planner is free to join the given tables in any order. For example,
|
the planner is free to join the given tables in any order. For
|
||||||
it could generate a query plan that joins A to B, using the WHERE clause
|
example, it could generate a query plan that joins A to B, using
|
||||||
a.id = b.id, and then joins C to this joined table, using the other
|
the <literal>WHERE</> condition <literal>a.id = b.id</>, and then
|
||||||
WHERE clause. Or it could join B to C and then join A to that result.
|
joins C to this joined table, using the other <literal>WHERE</>
|
||||||
Or it could join A to C and then join them with B --- but that would
|
condition. Or it could join B to C and then join A to that result.
|
||||||
be inefficient, since the full Cartesian product of A and C would have
|
Or it could join A to C and then join them with B --- but that
|
||||||
to be formed, there being no applicable WHERE clause to allow optimization
|
would be inefficient, since the full Cartesian product of A and C
|
||||||
of the join.
|
would have to be formed, there being no applicable condition in the
|
||||||
(All joins in the <productname>PostgreSQL</productname> executor happen
|
<literal>WHERE</> clause to allow optimization of the join. (All
|
||||||
between two input tables, so it's necessary to build up the result in one
|
joins in the <productname>PostgreSQL</productname> executor happen
|
||||||
or another of these fashions.) The important point is that these different
|
between two input tables, so it's necessary to build up the result
|
||||||
join possibilities give semantically equivalent results but may have hugely
|
in one or another of these fashions.) The important point is that
|
||||||
different execution costs. Therefore, the planner will explore all of them
|
these different join possibilities give semantically equivalent
|
||||||
to try to find the most efficient query plan.
|
results but may have hugely different execution costs. Therefore,
|
||||||
|
the planner will explore all of them to try to find the most
|
||||||
|
efficient query plan.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
@ -567,7 +571,7 @@ SELECT * FROM a,b,c WHERE a.id = b.id AND b.ref = c.id;
|
|||||||
search to a <firstterm>genetic</firstterm> probabilistic search
|
search to a <firstterm>genetic</firstterm> probabilistic search
|
||||||
through a limited number of possibilities. (The switch-over threshold is
|
through a limited number of possibilities. (The switch-over threshold is
|
||||||
set by the <varname>GEQO_THRESHOLD</varname> run-time
|
set by the <varname>GEQO_THRESHOLD</varname> run-time
|
||||||
parameter described in the <citetitle>Administrator's Guide</citetitle>.)
|
parameter described in the &cite-admin;.)
|
||||||
The genetic search takes less time, but it won't
|
The genetic search takes less time, but it won't
|
||||||
necessarily find the best possible plan.
|
necessarily find the best possible plan.
|
||||||
</para>
|
</para>
|
||||||
@ -575,9 +579,9 @@ SELECT * FROM a,b,c WHERE a.id = b.id AND b.ref = c.id;
|
|||||||
<para>
|
<para>
|
||||||
When the query involves outer joins, the planner has much less freedom
|
When the query involves outer joins, the planner has much less freedom
|
||||||
than it does for plain (inner) joins. For example, consider
|
than it does for plain (inner) joins. For example, consider
|
||||||
<programlisting>
|
<programlisting>
|
||||||
SELECT * FROM a LEFT JOIN (b JOIN c ON (b.ref = c.id)) ON (a.id = b.id);
|
SELECT * FROM a LEFT JOIN (b JOIN c ON (b.ref = c.id)) ON (a.id = b.id);
|
||||||
</programlisting>
|
</programlisting>
|
||||||
Although this query's restrictions are superficially similar to the
|
Although this query's restrictions are superficially similar to the
|
||||||
previous example, the semantics are different because a row must be
|
previous example, the semantics are different because a row must be
|
||||||
emitted for each row of A that has no matching row in the join of B and C.
|
emitted for each row of A that has no matching row in the join of B and C.
|
||||||
@ -587,27 +591,27 @@ SELECT * FROM a LEFT JOIN (b JOIN c ON (b.ref = c.id)) ON (a.id = b.id);
|
|||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
In <productname>PostgreSQL</productname> 7.1, the planner treats all
|
The <productname>PostgreSQL</productname> query planner treats all
|
||||||
explicit JOIN syntaxes as constraining the join order, even though
|
explicit <literal>JOIN</> syntaxes as constraining the join order, even though
|
||||||
it is not logically necessary to make such a constraint for inner
|
it is not logically necessary to make such a constraint for inner
|
||||||
joins. Therefore, although all of these queries give the same result:
|
joins. Therefore, although all of these queries give the same result:
|
||||||
<programlisting>
|
<programlisting>
|
||||||
SELECT * FROM a,b,c WHERE a.id = b.id AND b.ref = c.id;
|
SELECT * FROM a, b, c WHERE a.id = b.id AND b.ref = c.id;
|
||||||
SELECT * FROM a CROSS JOIN b CROSS JOIN c WHERE a.id = b.id AND b.ref = c.id;
|
SELECT * FROM a CROSS JOIN b CROSS JOIN c WHERE a.id = b.id AND b.ref = c.id;
|
||||||
SELECT * FROM a JOIN (b JOIN c ON (b.ref = c.id)) ON (a.id = b.id);
|
SELECT * FROM a JOIN (b JOIN c ON (b.ref = c.id)) ON (a.id = b.id);
|
||||||
</programlisting>
|
</programlisting>
|
||||||
the second and third take less time to plan than the first. This effect
|
but the second and third take less time to plan than the first. This effect
|
||||||
is not worth worrying about for only three tables, but it can be a
|
is not worth worrying about for only three tables, but it can be a
|
||||||
lifesaver with many tables.
|
lifesaver with many tables.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
You do not need to constrain the join order completely in order to
|
You do not need to constrain the join order completely in order to
|
||||||
cut search time, because it's OK to use JOIN operators in a plain
|
cut search time, because it's OK to use <literal>JOIN</> operators in a plain
|
||||||
FROM list. For example,
|
<literal>FROM</> list. For example,
|
||||||
<programlisting>
|
<programlisting>
|
||||||
SELECT * FROM a CROSS JOIN b, c, d, e WHERE ...;
|
SELECT * FROM a CROSS JOIN b, c, d, e WHERE ...;
|
||||||
</programlisting>
|
</programlisting>
|
||||||
forces the planner to join A to B before joining them to other tables,
|
forces the planner to join A to B before joining them to other tables,
|
||||||
but doesn't constrain its choices otherwise. In this example, the
|
but doesn't constrain its choices otherwise. In this example, the
|
||||||
number of possible join orders is reduced by a factor of 5.
|
number of possible join orders is reduced by a factor of 5.
|
||||||
@ -617,22 +621,22 @@ SELECT * FROM a CROSS JOIN b, c, d, e WHERE ...;
|
|||||||
If you have a mix of outer and inner joins in a complex query, you
|
If you have a mix of outer and inner joins in a complex query, you
|
||||||
might not want to constrain the planner's search for a good ordering
|
might not want to constrain the planner's search for a good ordering
|
||||||
of inner joins inside an outer join. You can't do that directly in the
|
of inner joins inside an outer join. You can't do that directly in the
|
||||||
JOIN syntax, but you can get around the syntactic limitation by using
|
<literal>JOIN</> syntax, but you can get around the syntactic limitation by using
|
||||||
subselects. For example,
|
subselects. For example,
|
||||||
<programlisting>
|
<programlisting>
|
||||||
SELECT * FROM d LEFT JOIN
|
SELECT * FROM d LEFT JOIN
|
||||||
(SELECT * FROM a, b, c WHERE ...) AS ss
|
(SELECT * FROM a, b, c WHERE ...) AS ss
|
||||||
ON (...);
|
ON (...);
|
||||||
</programlisting>
|
</programlisting>
|
||||||
Here, joining D must be the last step in the query plan, but the
|
Here, joining D must be the last step in the query plan, but the
|
||||||
planner is free to consider various join orders for A,B,C.
|
planner is free to consider various join orders for A, B, C.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
Constraining the planner's search in this way is a useful technique
|
Constraining the planner's search in this way is a useful technique
|
||||||
both for reducing planning time and for directing the planner to a
|
both for reducing planning time and for directing the planner to a
|
||||||
good query plan. If the planner chooses a bad join order by default,
|
good query plan. If the planner chooses a bad join order by default,
|
||||||
you can force it to choose a better order via JOIN syntax --- assuming
|
you can force it to choose a better order via <literal>JOIN</> syntax --- assuming
|
||||||
that you know of a better order, that is. Experimentation is recommended.
|
that you know of a better order, that is. Experimentation is recommended.
|
||||||
</para>
|
</para>
|
||||||
</sect1>
|
</sect1>
|
||||||
@ -658,6 +662,10 @@ SELECT * FROM d LEFT JOIN
|
|||||||
If you allow each insertion to be committed separately,
|
If you allow each insertion to be committed separately,
|
||||||
<productname>PostgreSQL</productname> is doing a lot of work for each
|
<productname>PostgreSQL</productname> is doing a lot of work for each
|
||||||
record added.
|
record added.
|
||||||
|
An additional benefit of doing all insertions in one transaction
|
||||||
|
is that if the insertion of one record were to fail then the
|
||||||
|
insertion of all records inserted up to that point would be rolled
|
||||||
|
back, so you won't be stuck with partially loaded data.
|
||||||
</para>
|
</para>
|
||||||
</sect2>
|
</sect2>
|
||||||
|
|
||||||
@ -696,7 +704,7 @@ SELECT * FROM d LEFT JOIN
|
|||||||
</sect2>
|
</sect2>
|
||||||
|
|
||||||
<sect2 id="populate-analyze">
|
<sect2 id="populate-analyze">
|
||||||
<title>ANALYZE Afterwards</title>
|
<title>Run ANALYZE Afterwards</title>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
It's a good idea to run <command>ANALYZE</command> or <command>VACUUM
|
It's a good idea to run <command>ANALYZE</command> or <command>VACUUM
|
||||||
|
@ -1,4 +1,4 @@
|
|||||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/queries.sgml,v 1.18 2002/10/20 05:05:46 tgl Exp $ -->
|
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/queries.sgml,v 1.19 2002/11/11 20:14:03 petere Exp $ -->
|
||||||
|
|
||||||
<chapter id="queries">
|
<chapter id="queries">
|
||||||
<title>Queries</title>
|
<title>Queries</title>
|
||||||
@ -668,7 +668,7 @@ SELECT <replaceable>select_list</replaceable>
|
|||||||
order in which the columns are listed does not matter. The
|
order in which the columns are listed does not matter. The
|
||||||
purpose is to reduce each group of rows sharing common values into
|
purpose is to reduce each group of rows sharing common values into
|
||||||
one group row that is representative of all rows in the group.
|
one group row that is representative of all rows in the group.
|
||||||
This is done to eliminate redundancy in the output and/or obtain
|
This is done to eliminate redundancy in the output and/or compute
|
||||||
aggregates that apply to these groups. For instance:
|
aggregates that apply to these groups. For instance:
|
||||||
<screen>
|
<screen>
|
||||||
<prompt>=></> <userinput>SELECT * FROM test1;</>
|
<prompt>=></> <userinput>SELECT * FROM test1;</>
|
||||||
@ -694,7 +694,12 @@ SELECT <replaceable>select_list</replaceable>
|
|||||||
In the second query, we could not have written <literal>SELECT *
|
In the second query, we could not have written <literal>SELECT *
|
||||||
FROM test1 GROUP BY x</literal>, because there is no single value
|
FROM test1 GROUP BY x</literal>, because there is no single value
|
||||||
for the column <literal>y</> that could be associated with each
|
for the column <literal>y</> that could be associated with each
|
||||||
group. In general, if a table is grouped, columns that are not
|
group. The grouped-by columns can be referenced in the select list since
|
||||||
|
they have a known constant value per group.
|
||||||
|
</para>
|
||||||
|
|
||||||
|
<para>
|
||||||
|
In general, if a table is grouped, columns that are not
|
||||||
used in the grouping cannot be referenced except in aggregate
|
used in the grouping cannot be referenced except in aggregate
|
||||||
expressions. An example with aggregate expressions is:
|
expressions. An example with aggregate expressions is:
|
||||||
<screen>
|
<screen>
|
||||||
@ -712,11 +717,6 @@ SELECT <replaceable>select_list</replaceable>
|
|||||||
linkend="functions-aggregate">.
|
linkend="functions-aggregate">.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
|
||||||
The grouped-by columns can be referenced in the select list since
|
|
||||||
they have a known constant value per group.
|
|
||||||
</para>
|
|
||||||
|
|
||||||
<tip>
|
<tip>
|
||||||
<para>
|
<para>
|
||||||
Grouping without aggregate expressions effectively calculates the
|
Grouping without aggregate expressions effectively calculates the
|
||||||
@ -740,7 +740,7 @@ SELECT product_id, p.name, (sum(s.units) * p.price) AS sales
|
|||||||
in the <literal>GROUP BY</> clause since they are referenced in
|
in the <literal>GROUP BY</> clause since they are referenced in
|
||||||
the query select list. (Depending on how exactly the products
|
the query select list. (Depending on how exactly the products
|
||||||
table is set up, name and price may be fully dependent on the
|
table is set up, name and price may be fully dependent on the
|
||||||
product ID, so the additional groups could theoretically be
|
product ID, so the additional groupings could theoretically be
|
||||||
unnecessary, but this is not implemented yet.) The column
|
unnecessary, but this is not implemented yet.) The column
|
||||||
<literal>s.units</> does not have to be in the <literal>GROUP
|
<literal>s.units</> does not have to be in the <literal>GROUP
|
||||||
BY</> list since it is only used in an aggregate expression
|
BY</> list since it is only used in an aggregate expression
|
||||||
@ -828,7 +828,7 @@ SELECT product_id, p.name, (sum(s.units) * (p.price - p.cost)) AS profit
|
|||||||
</para>
|
</para>
|
||||||
|
|
||||||
<sect2 id="queries-select-list-items">
|
<sect2 id="queries-select-list-items">
|
||||||
<title>Select List Items</title>
|
<title>Select-List Items</title>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
The simplest kind of select list is <literal>*</literal> which
|
The simplest kind of select list is <literal>*</literal> which
|
||||||
|
@ -1,5 +1,5 @@
|
|||||||
<!--
|
<!--
|
||||||
$Header: /cvsroot/pgsql/doc/src/sgml/query.sgml,v 1.27 2002/10/24 17:48:54 petere Exp $
|
$Header: /cvsroot/pgsql/doc/src/sgml/query.sgml,v 1.28 2002/11/11 20:14:03 petere Exp $
|
||||||
-->
|
-->
|
||||||
|
|
||||||
<chapter id="tutorial-sql">
|
<chapter id="tutorial-sql">
|
||||||
@ -13,7 +13,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/query.sgml,v 1.27 2002/10/24 17:48:54 peter
|
|||||||
<acronym>SQL</acronym> to perform simple operations. This
|
<acronym>SQL</acronym> to perform simple operations. This
|
||||||
tutorial is only intended to give you an introduction and is in no
|
tutorial is only intended to give you an introduction and is in no
|
||||||
way a complete tutorial on <acronym>SQL</acronym>. Numerous books
|
way a complete tutorial on <acronym>SQL</acronym>. Numerous books
|
||||||
have been written on <acronym>SQL92</acronym>, including <xref
|
have been written on <acronym>SQL</acronym>, including <xref
|
||||||
linkend="MELT93"> and <xref linkend="DATE97">.
|
linkend="MELT93"> and <xref linkend="DATE97">.
|
||||||
You should be aware that some <productname>PostgreSQL</productname>
|
You should be aware that some <productname>PostgreSQL</productname>
|
||||||
language features are extensions to the standard.
|
language features are extensions to the standard.
|
||||||
@ -44,7 +44,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/query.sgml,v 1.27 2002/10/24 17:48:54 peter
|
|||||||
|
|
||||||
The <literal>\i</literal> command reads in commands from the
|
The <literal>\i</literal> command reads in commands from the
|
||||||
specified file. The <literal>-s</literal> option puts you in
|
specified file. The <literal>-s</literal> option puts you in
|
||||||
single step mode which pauses before sending each query to the
|
single step mode which pauses before sending each statement to the
|
||||||
server. The commands used in this section are in the file
|
server. The commands used in this section are in the file
|
||||||
<filename>basics.sql</filename>.
|
<filename>basics.sql</filename>.
|
||||||
</para>
|
</para>
|
||||||
@ -502,7 +502,7 @@ SELECT *
|
|||||||
join operator will have each of its rows in the output at least
|
join operator will have each of its rows in the output at least
|
||||||
once, whereas the table on the right will only have those rows
|
once, whereas the table on the right will only have those rows
|
||||||
output that match some row of the left table. When outputting a
|
output that match some row of the left table. When outputting a
|
||||||
left-table row for which there is no right-table match, empty (NULL)
|
left-table row for which there is no right-table match, empty (null)
|
||||||
values are substituted for the right-table columns.
|
values are substituted for the right-table columns.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
@ -601,7 +601,7 @@ SELECT max(temp_lo) FROM weather;
|
|||||||
<para>
|
<para>
|
||||||
<indexterm><primary>subquery</primary></indexterm>
|
<indexterm><primary>subquery</primary></indexterm>
|
||||||
|
|
||||||
If we want to know what city (or cities) that reading occurred in,
|
If we wanted to know what city (or cities) that reading occurred in,
|
||||||
we might try
|
we might try
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
@ -615,7 +615,7 @@ SELECT city FROM weather WHERE temp_lo = max(temp_lo); <lineannotation>WRONG
|
|||||||
go into the aggregation stage; so it has to be evaluated before
|
go into the aggregation stage; so it has to be evaluated before
|
||||||
aggregate functions are computed.)
|
aggregate functions are computed.)
|
||||||
However, as is often the case
|
However, as is often the case
|
||||||
the query can be restated to accomplish the intended result; here
|
the query can be restated to accomplish the intended result, here
|
||||||
by using a <firstterm>subquery</firstterm>:
|
by using a <firstterm>subquery</firstterm>:
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
@ -630,9 +630,9 @@ SELECT city FROM weather
|
|||||||
(1 row)
|
(1 row)
|
||||||
</screen>
|
</screen>
|
||||||
|
|
||||||
This is OK because the sub-select is an independent computation
|
This is OK because the subquery is an independent computation
|
||||||
that computes its own aggregate separately from what is happening
|
that computes its own aggregate separately from what is happening
|
||||||
in the outer select.
|
in the outer query.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
@ -684,10 +684,18 @@ SELECT city, max(temp_lo)
|
|||||||
<programlisting>
|
<programlisting>
|
||||||
SELECT city, max(temp_lo)
|
SELECT city, max(temp_lo)
|
||||||
FROM weather
|
FROM weather
|
||||||
WHERE city LIKE 'S%'
|
WHERE city LIKE 'S%'<co id="co.tutorial-agg-like">
|
||||||
GROUP BY city
|
GROUP BY city
|
||||||
HAVING max(temp_lo) < 40;
|
HAVING max(temp_lo) < 40;
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
<calloutlist>
|
||||||
|
<callout arearefs="co.tutorial-agg-like">
|
||||||
|
<para>
|
||||||
|
The <literal>LIKE</literal> operator does pattern matching and
|
||||||
|
is explained in the &cite-user;.
|
||||||
|
</para>
|
||||||
|
</callout>
|
||||||
|
</calloutlist>
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
@ -729,7 +737,7 @@ SELECT city, max(temp_lo)
|
|||||||
You can update existing rows using the
|
You can update existing rows using the
|
||||||
<command>UPDATE</command> command.
|
<command>UPDATE</command> command.
|
||||||
Suppose you discover the temperature readings are
|
Suppose you discover the temperature readings are
|
||||||
all off by 2 degrees as of November 28, you may update the
|
all off by 2 degrees as of November 28. You may update the
|
||||||
data as follows:
|
data as follows:
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
@ -762,8 +770,8 @@ SELECT * FROM weather;
|
|||||||
</indexterm>
|
</indexterm>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
Suppose you are no longer interested in the weather of Hayward,
|
Suppose you are no longer interested in the weather of Hayward.
|
||||||
then you can do the following to delete those rows from the table.
|
Then you can do the following to delete those rows from the table.
|
||||||
Deletions are performed using the <command>DELETE</command>
|
Deletions are performed using the <command>DELETE</command>
|
||||||
command:
|
command:
|
||||||
<programlisting>
|
<programlisting>
|
||||||
@ -786,7 +794,7 @@ SELECT * FROM weather;
|
|||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
One should be wary of queries of the form
|
One should be wary of statements of the form
|
||||||
<synopsis>
|
<synopsis>
|
||||||
DELETE FROM <replaceable>tablename</replaceable>;
|
DELETE FROM <replaceable>tablename</replaceable>;
|
||||||
</synopsis>
|
</synopsis>
|
||||||
|
@ -1,5 +1,5 @@
|
|||||||
<!--
|
<!--
|
||||||
$Header: /cvsroot/pgsql/doc/src/sgml/runtime.sgml,v 1.149 2002/11/08 17:37:52 tgl Exp $
|
$Header: /cvsroot/pgsql/doc/src/sgml/runtime.sgml,v 1.150 2002/11/11 20:14:03 petere Exp $
|
||||||
-->
|
-->
|
||||||
|
|
||||||
<Chapter Id="runtime">
|
<Chapter Id="runtime">
|
||||||
@ -11,7 +11,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/runtime.sgml,v 1.149 2002/11/08 17:37:52 tg
|
|||||||
</para>
|
</para>
|
||||||
|
|
||||||
<sect1 id="postgres-user">
|
<sect1 id="postgres-user">
|
||||||
<title>The <productname>PostgreSQL</productname> user account</title>
|
<title>The <productname>PostgreSQL</productname> User Account</title>
|
||||||
|
|
||||||
<indexterm>
|
<indexterm>
|
||||||
<primary>postgres user</primary>
|
<primary>postgres user</primary>
|
||||||
@ -37,7 +37,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/runtime.sgml,v 1.149 2002/11/08 17:37:52 tg
|
|||||||
</sect1>
|
</sect1>
|
||||||
|
|
||||||
<sect1 id="creating-cluster">
|
<sect1 id="creating-cluster">
|
||||||
<title>Creating a database cluster</title>
|
<title>Creating a Database Cluster</title>
|
||||||
|
|
||||||
<indexterm>
|
<indexterm>
|
||||||
<primary>database cluster</primary>
|
<primary>database cluster</primary>
|
||||||
@ -152,7 +152,7 @@ set to "C". For more information see the Administrator's Guide.
|
|||||||
</screen>
|
</screen>
|
||||||
This is intended to warn you that the currently selected locale
|
This is intended to warn you that the currently selected locale
|
||||||
will cause indexes to be sorted in an order that prevents them from
|
will cause indexes to be sorted in an order that prevents them from
|
||||||
being used for LIKE and regular-expression searches. If you need
|
being used for <literal>LIKE</> and regular-expression searches. If you need
|
||||||
good performance in such searches, you should set your current
|
good performance in such searches, you should set your current
|
||||||
locale to <literal>C</> and re-run <command>initdb</command>, e.g.,
|
locale to <literal>C</> and re-run <command>initdb</command>, e.g.,
|
||||||
by running <literal>initdb --lc-collate=C</literal>. The sort
|
by running <literal>initdb --lc-collate=C</literal>. The sort
|
||||||
@ -165,7 +165,7 @@ set to "C". For more information see the Administrator's Guide.
|
|||||||
</sect1>
|
</sect1>
|
||||||
|
|
||||||
<sect1 id="postmaster-start">
|
<sect1 id="postmaster-start">
|
||||||
<title>Starting the database server</title>
|
<title>Starting the Database Server</title>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
<indexterm>
|
<indexterm>
|
||||||
@ -229,7 +229,7 @@ pg_ctl start -l logfile
|
|||||||
|
|
||||||
<para>
|
<para>
|
||||||
Normally, you will want to start the database server when the
|
Normally, you will want to start the database server when the
|
||||||
computer boots. Auto-start scripts are operating-system specific.
|
computer boots. Autostart scripts are operating system-specific.
|
||||||
There are a few distributed with
|
There are a few distributed with
|
||||||
<productname>PostgreSQL</productname> in the
|
<productname>PostgreSQL</productname> in the
|
||||||
<filename>/contrib/start-scripts</> directory. This may require root
|
<filename>/contrib/start-scripts</> directory. This may require root
|
||||||
@ -384,13 +384,13 @@ IpcSemaphoreCreate: semget(key=5440026, num=16, 01600) failed: No space left on
|
|||||||
means your kernel's limit on the number of System V semaphores is
|
means your kernel's limit on the number of System V semaphores is
|
||||||
smaller than the number <productname>PostgreSQL</productname> wants
|
smaller than the number <productname>PostgreSQL</productname> wants
|
||||||
to create. As above, you may be able to work around the problem by
|
to create. As above, you may be able to work around the problem by
|
||||||
starting the postmaster with a reduced number of backend processes
|
starting the postmaster with a reduced number of allowed connections
|
||||||
(<option>-N</option> switch), but you'll eventually want to
|
(<option>-N</option> switch), but you'll eventually want to
|
||||||
increase the kernel limit.
|
increase the kernel limit.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
If you get an <quote>illegal system call</> error, it is likely
|
If you get an <quote>illegal system call</> error, it is likely that
|
||||||
shared memory or semaphores are not supported in your kernel at
|
shared memory or semaphores are not supported in your kernel at
|
||||||
all. In that case your only option is to reconfigure the kernel to
|
all. In that case your only option is to reconfigure the kernel to
|
||||||
enable these features.
|
enable these features.
|
||||||
@ -456,7 +456,7 @@ psql: could not connect to server: Connection refused
|
|||||||
</sect1>
|
</sect1>
|
||||||
|
|
||||||
<sect1 id="runtime-config">
|
<sect1 id="runtime-config">
|
||||||
<Title>Run-time configuration</Title>
|
<Title>Run-time Configuration</Title>
|
||||||
|
|
||||||
<indexterm>
|
<indexterm>
|
||||||
<primary>configuration</primary>
|
<primary>configuration</primary>
|
||||||
@ -558,7 +558,7 @@ env PGOPTIONS='-c geqo=off' psql
|
|||||||
<title>pg_settings</title>
|
<title>pg_settings</title>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
<structname>pg_settings</structname> virtual table allows display and update
|
The <structname>pg_settings</structname> virtual table allows display and update
|
||||||
of current session run-time parameters. There is one entry for each of the
|
of current session run-time parameters. There is one entry for each of the
|
||||||
available parameters provided by <command>SHOW ALL</command>. But it is
|
available parameters provided by <command>SHOW ALL</command>. But it is
|
||||||
in a form that allows it to be joined with other relations and have a
|
in a form that allows it to be joined with other relations and have a
|
||||||
@ -579,28 +579,25 @@ env PGOPTIONS='-c geqo=off' psql
|
|||||||
<table>
|
<table>
|
||||||
<title>pg_settings Columns</title>
|
<title>pg_settings Columns</title>
|
||||||
|
|
||||||
<tgroup cols=4>
|
<tgroup cols=3>
|
||||||
<thead>
|
<thead>
|
||||||
<row>
|
<row>
|
||||||
<entry>Name</entry>
|
<entry>Name</entry>
|
||||||
<entry>Type</entry>
|
<entry>Type</entry>
|
||||||
<entry>References</entry>
|
|
||||||
<entry>Description</entry>
|
<entry>Description</entry>
|
||||||
</row>
|
</row>
|
||||||
</thead>
|
</thead>
|
||||||
|
|
||||||
<tbody>
|
<tbody>
|
||||||
<row>
|
<row>
|
||||||
<entry>name</entry>
|
<entry><literal>name</literal></entry>
|
||||||
<entry><type>text</type></entry>
|
<entry><type>text</type></entry>
|
||||||
<entry></entry>
|
|
||||||
<entry>The name of a current session run-time parameter</entry>
|
<entry>The name of a current session run-time parameter</entry>
|
||||||
</row>
|
</row>
|
||||||
|
|
||||||
<row>
|
<row>
|
||||||
<entry>setting</entry>
|
<entry><literal>setting</literal></entry>
|
||||||
<entry><type>text</type></entry>
|
<entry><type>text</type></entry>
|
||||||
<entry></entry>
|
|
||||||
<entry>The value of a current session run-time parameter</entry>
|
<entry>The value of a current session run-time parameter</entry>
|
||||||
</row>
|
</row>
|
||||||
</tbody>
|
</tbody>
|
||||||
@ -630,7 +627,7 @@ env PGOPTIONS='-c geqo=off' psql
|
|||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
Sets the optimizer's estimate of the cost of processing each
|
Sets the optimizer's estimate of the cost of processing each
|
||||||
operator in a WHERE clause. This is measured as a fraction of
|
operator in a <literal>WHERE</> clause. This is measured as a fraction of
|
||||||
the cost of a sequential page fetch.
|
the cost of a sequential page fetch.
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
@ -860,85 +857,93 @@ env PGOPTIONS='-c geqo=off' psql
|
|||||||
<term><varname>SERVER_MIN_MESSAGES</varname> (<type>string</type>)</term>
|
<term><varname>SERVER_MIN_MESSAGES</varname> (<type>string</type>)</term>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
This controls how much detail is written to the server logs. The
|
This controls how much message detail is written to the server
|
||||||
default is <literal>NOTICE</>. Valid values are <literal>DEBUG5</>,
|
logs. Valid values are <literal>DEBUG5</>,
|
||||||
<literal>DEBUG4</>, <literal>DEBUG3</>, <literal>DEBUG2</>,
|
<literal>DEBUG4</>, <literal>DEBUG3</>, <literal>DEBUG2</>,
|
||||||
<literal>DEBUG1</>, <literal>INFO</>, <literal>NOTICE</>,
|
<literal>DEBUG1</>, <literal>INFO</>, <literal>NOTICE</>,
|
||||||
<literal>WARNING</>, <literal>ERROR</>, <literal>LOG</>,
|
<literal>WARNING</>, <literal>ERROR</>, <literal>LOG</>,
|
||||||
<literal>FATAL</>, and <literal>PANIC</>. Later values send less
|
<literal>FATAL</>, and <literal>PANIC</>. Later values send
|
||||||
detail to the logs. <literal>LOG</> has a different precedence
|
less detail to the logs. The default is <literal>NOTICE</>.
|
||||||
here than in <literal>CLIENT_MIN_MESSAGES</>.
|
Note that <literal>LOG</> has a different precedence here than
|
||||||
|
in <literal>CLIENT_MIN_MESSAGES</>.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
Here is a summary of the various message types:
|
Here is a summary of the various message types:
|
||||||
<variablelist>
|
<variablelist>
|
||||||
<varlistentry>
|
<varlistentry>
|
||||||
<term><varname>DEBUG[1-5]</varname></term>
|
<term><literal>DEBUG[1-5]</literal></term>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
This provides information for use by developers.
|
Provides information for use by developers.
|
||||||
</para>
|
|
||||||
</listitem>
|
|
||||||
</varlistentry>
|
|
||||||
<varlistentry>
|
|
||||||
<term><varname>INFO</varname></term>
|
|
||||||
<listitem>
|
|
||||||
<para>
|
|
||||||
This provides information requested by the user, e.g.
|
|
||||||
<command>SET</>.
|
|
||||||
</para>
|
|
||||||
</listitem>
|
|
||||||
</varlistentry>
|
|
||||||
<varlistentry>
|
|
||||||
<term><varname>NOTICE</varname></term>
|
|
||||||
<listitem>
|
|
||||||
<para>
|
|
||||||
This provides information that may be helpful to users, e.g.
|
|
||||||
truncation of long identifiers, sequence creation as part of
|
|
||||||
<command>SERIAL</>.
|
|
||||||
</para>
|
|
||||||
</listitem>
|
|
||||||
</varlistentry>
|
|
||||||
<varlistentry>
|
|
||||||
<term><varname>WARNING</varname></term>
|
|
||||||
<listitem>
|
|
||||||
<para>
|
|
||||||
This provides warnings to the user, e.g. <command>COMMIT</>
|
|
||||||
outside a transaction.
|
|
||||||
</para>
|
|
||||||
</listitem>
|
|
||||||
</varlistentry>
|
|
||||||
<varlistentry>
|
|
||||||
<term><varname>ERROR</varname></term>
|
|
||||||
<listitem>
|
|
||||||
<para>
|
|
||||||
Reports the error that caused the transaction to abort.
|
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
|
|
||||||
<varlistentry>
|
<varlistentry>
|
||||||
<term><varname>LOG</varname></term>
|
<term><literal>INFO</literal></term>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
This reports information of interest to administrators, e.g.
|
Provides information implicitly requested by the user,
|
||||||
|
e.g., during <command>VACUUM VERBOSE</>.
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
</varlistentry>
|
||||||
|
|
||||||
|
<varlistentry>
|
||||||
|
<term><literal>NOTICE</literal></term>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
Provides information that may be helpful to users, e.g.,
|
||||||
|
truncation of long identifiers and index creation as part
|
||||||
|
of primary keys.
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
</varlistentry>
|
||||||
|
|
||||||
|
<varlistentry>
|
||||||
|
<term><literal>WARNING</literal></term>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
Provides warnings to the user, e.g., <command>COMMIT</>
|
||||||
|
outside a transaction.
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
</varlistentry>
|
||||||
|
|
||||||
|
<varlistentry>
|
||||||
|
<term><literal>ERROR</literal></term>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
Reports the error that caused a transaction to abort.
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
</varlistentry>
|
||||||
|
|
||||||
|
<varlistentry>
|
||||||
|
<term><literal>LOG</literal></term>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
Reports information of interest to administrators, e.g.,
|
||||||
checkpoint activity.
|
checkpoint activity.
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
|
|
||||||
<varlistentry>
|
<varlistentry>
|
||||||
<term><varname>FATAL</varname></term>
|
<term><literal>FATAL</literal></term>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
This reports why the backend session terminated.
|
Reports why a backend session terminated.
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
|
|
||||||
<varlistentry>
|
<varlistentry>
|
||||||
<term><varname>PANIC</varname></term>
|
<term><literal>PANIC</literal></term>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
This reports why all backends restarted.
|
Reports why all backend sessions restarted.
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
@ -951,15 +956,15 @@ env PGOPTIONS='-c geqo=off' psql
|
|||||||
<term><varname>CLIENT_MIN_MESSAGES</varname> (<type>string</type>)</term>
|
<term><varname>CLIENT_MIN_MESSAGES</varname> (<type>string</type>)</term>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
This controls how much detail is written to the client. The
|
This controls how much message detail is written to the
|
||||||
default is <literal>NOTICE</>. Valid values are
|
client. Valid values are <literal>DEBUG5</>,
|
||||||
<literal>DEBUG5</>, <literal>DEBUG4</>, <literal>DEBUG3</>,
|
<literal>DEBUG4</>, <literal>DEBUG3</>, <literal>DEBUG2</>,
|
||||||
<literal>DEBUG2</>, <literal>DEBUG1</>, <literal>LOG</>,
|
<literal>DEBUG1</>, <literal>LOG</>, <literal>NOTICE</>,
|
||||||
<literal>NOTICE</>, <literal>WARNING</>, and <literal>ERROR</>.
|
<literal>WARNING</>, and <literal>ERROR</>. Later values send
|
||||||
Later values send less information to the user. <literal>LOG</>
|
less information to the client. The default is
|
||||||
has a different precedence here than in
|
<literal>NOTICE</>. Note that <literal>LOG</> has a different
|
||||||
<literal>SERVER_MIN_MESSAGES</>. Also see that section for an
|
precedence here than in <literal>SERVER_MIN_MESSAGES</>. Also
|
||||||
explanation of the various values.
|
see that section for an explanation of the various values.
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
@ -973,7 +978,7 @@ env PGOPTIONS='-c geqo=off' psql
|
|||||||
to turn this on, as it might expose programming mistakes. To use
|
to turn this on, as it might expose programming mistakes. To use
|
||||||
this option, the macro <literal>USE_ASSERT_CHECKING</literal>
|
this option, the macro <literal>USE_ASSERT_CHECKING</literal>
|
||||||
must be defined when <productname>PostgreSQL</productname> is
|
must be defined when <productname>PostgreSQL</productname> is
|
||||||
built (accomplished by the configure option
|
built (accomplished by the <command>configure</command> option
|
||||||
<option>--enable-cassert</option>). Note that
|
<option>--enable-cassert</option>). Note that
|
||||||
<literal>DEBUG_ASSERTIONS</literal> defaults to on if
|
<literal>DEBUG_ASSERTIONS</literal> defaults to on if
|
||||||
<productname>PostgreSQL</productname> has been built with
|
<productname>PostgreSQL</productname> has been built with
|
||||||
@ -990,7 +995,7 @@ env PGOPTIONS='-c geqo=off' psql
|
|||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
These flags enable various debugging output to be sent to the
|
These flags enable various debugging output to be sent to the
|
||||||
server log. For each executed query, prints either the query text,
|
server log. For each executed query, print either the query text,
|
||||||
the resulting parse tree, the query rewriter output, or the execution
|
the resulting parse tree, the query rewriter output, or the execution
|
||||||
plan. <option>DEBUG_PRETTY_PRINT</option> indents these displays
|
plan. <option>DEBUG_PRETTY_PRINT</option> indents these displays
|
||||||
to produce a more readable but much longer output format.
|
to produce a more readable but much longer output format.
|
||||||
@ -1032,22 +1037,39 @@ env PGOPTIONS='-c geqo=off' psql
|
|||||||
</listitem>
|
</listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
|
|
||||||
|
<varlistentry>
|
||||||
|
<term><varname>LOG_DURATION</varname> (<type>boolean</type>)</term>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
Causes the duration of every completed statement to be logged.
|
||||||
|
To use this option, enable <varname>LOG_STATEMENT</> and
|
||||||
|
<varname>LOG_PID</> so you can link the statement to the
|
||||||
|
duration using the process ID.
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
</varlistentry>
|
||||||
|
|
||||||
<varlistentry>
|
<varlistentry>
|
||||||
<term><varname>LOG_MIN_ERROR_STATEMENT</varname> (<type>string</type>)</term>
|
<term><varname>LOG_MIN_ERROR_STATEMENT</varname> (<type>string</type>)</term>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
This controls which message types output the original query to
|
This controls for which message levels the SQL statement
|
||||||
the server logs. All queries matching the setting or higher are
|
causing that message is to be recorded in the server log. All
|
||||||
logged. The default is <literal>PANIC</literal> (effectively
|
statements causing a message of the level of the setting or
|
||||||
"off"). Valid values are <literal>DEBUG5</literal>,
|
higher are logged. The default is <literal>PANIC</literal>
|
||||||
<literal>DEBUG4</literal>, <literal>DEBUG3</literal>,
|
(effectively turning this feature off). Valid values are
|
||||||
<literal>DEBUG2</literal>, <literal>DEBUG1</literal>,
|
<literal>DEBUG5</literal>, <literal>DEBUG4</literal>,
|
||||||
<literal>INFO</literal>, <literal>NOTICE</literal>,
|
<literal>DEBUG3</literal>, <literal>DEBUG2</literal>,
|
||||||
<literal>WARNING</literal>, <literal>ERROR</literal>,
|
<literal>DEBUG1</literal>, <literal>INFO</literal>,
|
||||||
<literal>FATAL</literal>, and <literal>PANIC</literal>.
|
<literal>NOTICE</literal>, <literal>WARNING</literal>,
|
||||||
|
<literal>ERROR</literal>, <literal>FATAL</literal>, and
|
||||||
|
<literal>PANIC</literal>. For example, if you set this to
|
||||||
|
<literal>ERROR</literal> then all SQL statements causing
|
||||||
|
errors, fatal errors, or panics will be logged.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
It is recommended you enable <literal>LOG_PID</literal> as well
|
It is recommended you enable <varname>LOG_PID</varname> as well
|
||||||
so you can more easily match the error statement with the error
|
so you can more easily match the error statement with the error
|
||||||
message.
|
message.
|
||||||
</para>
|
</para>
|
||||||
@ -1071,18 +1093,7 @@ env PGOPTIONS='-c geqo=off' psql
|
|||||||
<term><varname>LOG_STATEMENT</varname> (<type>boolean</type>)</term>
|
<term><varname>LOG_STATEMENT</varname> (<type>boolean</type>)</term>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
Prints each query received.
|
Causes each SQL statement to be logged.
|
||||||
</para>
|
|
||||||
</listitem>
|
|
||||||
</varlistentry>
|
|
||||||
|
|
||||||
<varlistentry>
|
|
||||||
<term><varname>LOG_DURATION</varname> (<type>boolean</type>)</term>
|
|
||||||
<listitem>
|
|
||||||
<para>
|
|
||||||
Prints the duration of every completed query. To use this option,
|
|
||||||
enable <literal>LOG_STATEMENT</> and <literal>LOG_PID</> so you
|
|
||||||
can link the original query to the duration using the process id.
|
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
@ -1186,9 +1197,12 @@ env PGOPTIONS='-c geqo=off' psql
|
|||||||
This option determines the <application>syslog</application>
|
This option determines the <application>syslog</application>
|
||||||
<quote>facility</quote> to be used when
|
<quote>facility</quote> to be used when
|
||||||
<application>syslog</application> is enabled. You may choose
|
<application>syslog</application> is enabled. You may choose
|
||||||
from LOCAL0, LOCAL1, LOCAL2, LOCAL3, LOCAL4, LOCAL5, LOCAL6,
|
from <literal>LOCAL0</>, <literal>LOCAL1</>,
|
||||||
LOCAL7; the default is LOCAL0. See also the documentation of
|
<literal>LOCAL2</>, <literal>LOCAL3</>, <literal>LOCAL4</>,
|
||||||
your system's <application>syslog</application>.
|
<literal>LOCAL5</>, <literal>LOCAL6</>, <literal>LOCAL7</>;
|
||||||
|
the default is <literal>LOCAL0</>. See also the
|
||||||
|
documentation of your system's
|
||||||
|
<application>syslog</application>.
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
@ -1221,12 +1235,12 @@ env PGOPTIONS='-c geqo=off' psql
|
|||||||
</sect2>
|
</sect2>
|
||||||
|
|
||||||
<sect2 id="runtime-config-general">
|
<sect2 id="runtime-config-general">
|
||||||
<title>General operation</title>
|
<title>General Operation</title>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
<variablelist>
|
<variablelist>
|
||||||
<varlistentry>
|
<varlistentry>
|
||||||
<term><varname>AUTOCOMMIT</varname> (<type>bool</type>)</term>
|
<term><varname>AUTOCOMMIT</varname> (<type>boolean</type>)</term>
|
||||||
<indexterm><primary>autocommit</></>
|
<indexterm><primary>autocommit</></>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
@ -1254,7 +1268,7 @@ env PGOPTIONS='-c geqo=off' psql
|
|||||||
Once another command is issued, a transaction block
|
Once another command is issued, a transaction block
|
||||||
begins and any <command>SET</>, <command>SHOW</>, or
|
begins and any <command>SET</>, <command>SHOW</>, or
|
||||||
<command>RESET</> commands are considered to be part of the
|
<command>RESET</> commands are considered to be part of the
|
||||||
transaction, i.e. they are committed or rolled back depending
|
transaction, i.e., they are committed or rolled back depending
|
||||||
on the completion status of the transaction. To execute a
|
on the completion status of the transaction. To execute a
|
||||||
<command>SET</>, <command>SHOW</>, or <command>RESET</>
|
<command>SET</>, <command>SHOW</>, or <command>RESET</>
|
||||||
command at the start of a transaction block, use <command>BEGIN</>
|
command at the start of a transaction block, use <command>BEGIN</>
|
||||||
@ -1276,7 +1290,7 @@ env PGOPTIONS='-c geqo=off' psql
|
|||||||
</varlistentry>
|
</varlistentry>
|
||||||
|
|
||||||
<varlistentry>
|
<varlistentry>
|
||||||
<term><varname>AUSTRALIAN_TIMEZONES</varname> (<type>bool</type>)</term>
|
<term><varname>AUSTRALIAN_TIMEZONES</varname> (<type>boolean</type>)</term>
|
||||||
<indexterm><primary>Australian time zones</></>
|
<indexterm><primary>Australian time zones</></>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
@ -1330,19 +1344,33 @@ env PGOPTIONS='-c geqo=off' psql
|
|||||||
<term><varname>DB_USER_NAMESPACE</varname> (<type>boolean</type>)</term>
|
<term><varname>DB_USER_NAMESPACE</varname> (<type>boolean</type>)</term>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
This allows per-database user names. You can create users as <literal>
|
This allows per-database user names. It is off by default.
|
||||||
username@dbname</>. When <literal>username</> is passed by the client,
|
|
||||||
<literal>@</> and the database name is appended to the user name and
|
|
||||||
that database-specific user name is looked up by the server.
|
|
||||||
When creating user names containing <literal>@</>, you will need
|
|
||||||
to quote the user name.
|
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
|
<para>
|
||||||
|
If this is on, create users as <literal> username@dbname</>.
|
||||||
|
When <literal>username</> is passed by a connecting client,
|
||||||
|
<literal>@</> and the database name is appended to the user
|
||||||
|
name and that database-specific user name is looked up by the
|
||||||
|
server. Note that when you create users with names containing
|
||||||
|
<literal>@</> within the SQL environment, you will need to
|
||||||
|
quote the user name.
|
||||||
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
With this option enabled, you can still create ordinary global
|
With this option enabled, you can still create ordinary global
|
||||||
users. Simply append <literal>@</> when specifying the user name
|
users. Simply append <literal>@</> when specifying the user
|
||||||
in the client. The <literal>@</> will be stripped off and looked up
|
name in the client. The <literal>@</> will be stripped off
|
||||||
by the server.
|
before the user name is looked up by the server.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
|
<note>
|
||||||
|
<para>
|
||||||
|
This feature is intended as a temporary measure until a
|
||||||
|
complete solution is found. At that time, this option will
|
||||||
|
be removed.
|
||||||
|
</para>
|
||||||
|
</note>
|
||||||
</listitem>
|
</listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
|
|
||||||
@ -1393,7 +1421,7 @@ env PGOPTIONS='-c geqo=off' psql
|
|||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
Consult the <citetitle>PostgreSQL User's Guide</citetitle> and
|
Consult the &cite-user; and
|
||||||
the command <command>SET TRANSACTION</command> for more
|
the command <command>SET TRANSACTION</command> for more
|
||||||
information.
|
information.
|
||||||
</para>
|
</para>
|
||||||
@ -1424,11 +1452,9 @@ env PGOPTIONS='-c geqo=off' psql
|
|||||||
distribution are installed. (Use <literal>pg_config
|
distribution are installed. (Use <literal>pg_config
|
||||||
--pkglibdir</literal> to print the name of this directory.) For
|
--pkglibdir</literal> to print the name of this directory.) For
|
||||||
example:
|
example:
|
||||||
<informalexample>
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
dynamic_library_path = '/usr/local/lib/postgresql:/home/my_project/lib:$libdir'
|
dynamic_library_path = '/usr/local/lib/postgresql:/home/my_project/lib:$libdir'
|
||||||
</programlisting>
|
</programlisting>
|
||||||
</informalexample>
|
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
@ -1690,8 +1716,8 @@ dynamic_library_path = '/usr/local/lib/postgresql:/home/my_project/lib:$libdir'
|
|||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
When a password is specified in <command>CREATE USER</> or
|
When a password is specified in <command>CREATE USER</> or
|
||||||
<command>ALTER USER</> without writing either ENCRYPTED or
|
<command>ALTER USER</> without writing either <literal>ENCRYPTED</> or
|
||||||
UNENCRYPTED, this flag determines whether the password is to be
|
<literal>UNENCRYPTED</>, this flag determines whether the password is to be
|
||||||
encrypted. The default is on (encrypt the password).
|
encrypted. The default is on (encrypt the password).
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
@ -1714,37 +1740,37 @@ dynamic_library_path = '/usr/local/lib/postgresql:/home/my_project/lib:$libdir'
|
|||||||
<indexterm><primary>namespaces</></>
|
<indexterm><primary>namespaces</></>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
This variable specifies the order in which namespaces are searched
|
This variable specifies the order in which schemas are searched
|
||||||
when an object (table, data type, function, etc) is referenced by a
|
when an object (table, data type, function, etc.) is referenced by a
|
||||||
simple name with no schema component. When there are objects of
|
simple name with no schema component. When there are objects of
|
||||||
identical names in different namespaces, the one found first
|
identical names in different schemas, the one found first
|
||||||
in the search path is used. An object that is not in any of the
|
in the search path is used. An object that is not in any of the
|
||||||
namespaces in the search path can only be referenced by specifying
|
schemas in the search path can only be referenced by specifying
|
||||||
its containing namespace with a qualified (dotted) name.
|
its containing schema with a qualified (dotted) name.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
The value for search_path has to be a comma-separated
|
The value for <varname>search_path</varname> has to be a comma-separated
|
||||||
list of namespace (schema) names. If one of the list items is
|
list of schema names. If one of the list items is
|
||||||
the special value <literal>$user</literal>, then the namespace
|
the special value <literal>$user</literal>, then the schema
|
||||||
having the same name as the SESSION_USER is substituted, if there
|
having the same name as the <function>SESSION_USER</> is substituted, if there
|
||||||
is such a namespace. (If not, <literal>$user</literal> is ignored.)
|
is such a schema. (If not, <literal>$user</literal> is ignored.)
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
The system catalog namespace, <literal>pg_catalog</>, is always
|
The system catalog schema, <literal>pg_catalog</>, is always
|
||||||
searched, whether it is mentioned in the path or not. If it is
|
searched, whether it is mentioned in the path or not. If it is
|
||||||
mentioned in the path then it will be searched in the specified
|
mentioned in the path then it will be searched in the specified
|
||||||
order. If <literal>pg_catalog</> is not in the path then it will
|
order. If <literal>pg_catalog</> is not in the path then it will
|
||||||
be searched <emphasis>before</> searching any of the path items.
|
be searched <emphasis>before</> searching any of the path items.
|
||||||
It should also be noted that the temporary-table namespace,
|
It should also be noted that the temporary-table schema,
|
||||||
<literal>pg_temp_nnn</>, is implicitly searched before any of
|
<literal>pg_temp_<replaceable>nnn</></>, is implicitly searched before any of
|
||||||
these.
|
these.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
When objects are created without specifying a particular target
|
When objects are created without specifying a particular target
|
||||||
namespace, they will be placed in the first namespace listed
|
schema, they will be placed in the first schema listed
|
||||||
in the search path. An error is reported if the search path is
|
in the search path. An error is reported if the search path is
|
||||||
empty.
|
empty.
|
||||||
</para>
|
</para>
|
||||||
@ -1752,21 +1778,14 @@ dynamic_library_path = '/usr/local/lib/postgresql:/home/my_project/lib:$libdir'
|
|||||||
<para>
|
<para>
|
||||||
The default value for this parameter is
|
The default value for this parameter is
|
||||||
<literal>'$user, public'</literal> (where the second part will be
|
<literal>'$user, public'</literal> (where the second part will be
|
||||||
ignored if there is no namespace named <literal>public</>).
|
ignored if there is no schema named <literal>public</>).
|
||||||
This supports shared use of a database (where no users
|
This supports shared use of a database (where no users
|
||||||
have private namespaces, and all share use of <literal>public</>),
|
have private schemas, and all share use of <literal>public</>),
|
||||||
private per-user namespaces, and combinations of these. Other
|
private per-user schemas, and combinations of these. Other
|
||||||
effects can be obtained by altering the default search path
|
effects can be obtained by altering the default search path
|
||||||
setting, either globally or per-user.
|
setting, either globally or per-user.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
|
||||||
By default, a newly created database will contain a world-writable
|
|
||||||
namespace named <literal>public</>, but no private namespaces.
|
|
||||||
The administrator may choose to restrict permissions on
|
|
||||||
<literal>public</> or even remove it, if that suits his purposes.
|
|
||||||
</para>
|
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
<indexterm>
|
<indexterm>
|
||||||
<primary>schemas</primary>
|
<primary>schemas</primary>
|
||||||
@ -1779,6 +1798,10 @@ dynamic_library_path = '/usr/local/lib/postgresql:/home/my_project/lib:$libdir'
|
|||||||
shows how the requests appearing in <varname>search_path</varname>
|
shows how the requests appearing in <varname>search_path</varname>
|
||||||
were resolved.
|
were resolved.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
|
<para>
|
||||||
|
For more information on schema handling, see the &cite-user;.
|
||||||
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
|
|
||||||
@ -1807,10 +1830,10 @@ dynamic_library_path = '/usr/local/lib/postgresql:/home/my_project/lib:$libdir'
|
|||||||
<term><varname>SILENT_MODE</varname> (<type>bool</type>)</term>
|
<term><varname>SILENT_MODE</varname> (<type>bool</type>)</term>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
Runs postmaster silently. If this option is set, the postmaster
|
Runs the server silently. If this option is set, the server
|
||||||
will automatically run in background and any controlling ttys
|
will automatically run in background and any controlling ttys
|
||||||
are disassociated, thus no messages are written to standard
|
are disassociated, thus no messages are written to standard
|
||||||
output or standard error (same effect as postmaster's -S
|
output or standard error (same effect as <command>postmaster</>'s <option>-S</option>
|
||||||
option). Unless some logging system such as
|
option). Unless some logging system such as
|
||||||
<application>syslog</> is enabled, using this option is
|
<application>syslog</> is enabled, using this option is
|
||||||
discouraged since it makes it impossible to see error messages.
|
discouraged since it makes it impossible to see error messages.
|
||||||
@ -1824,14 +1847,14 @@ dynamic_library_path = '/usr/local/lib/postgresql:/home/my_project/lib:$libdir'
|
|||||||
<para>
|
<para>
|
||||||
Specifies the amount of memory to be used by internal sorts and
|
Specifies the amount of memory to be used by internal sorts and
|
||||||
hashes before switching to temporary disk files. The value is
|
hashes before switching to temporary disk files. The value is
|
||||||
specified in kilobytes, and defaults to 1024 kilobytes (1MB).
|
specified in kilobytes, and defaults to 1024 kilobytes (1 MB).
|
||||||
Note that for a complex query, several sorts might be running in
|
Note that for a complex query, several sorts might be running in
|
||||||
parallel, and each one will be allowed to use as much memory as
|
parallel, and each one will be allowed to use as much memory as
|
||||||
this value specifies before it starts to put data into temporary
|
this value specifies before it starts to put data into temporary
|
||||||
files. Also, each running backend could be doing one or more
|
files. Also, each running backend could be doing one or more
|
||||||
sorts simultaneously, so the total memory used could be many
|
sorts simultaneously, so the total memory used could be many
|
||||||
times the value of <varname>SORT_MEM</varname>. Sorts are used
|
times the value of <varname>SORT_MEM</varname>. Sorts are used
|
||||||
by ORDER BY, merge joins, and CREATE INDEX.
|
by <literal>ORDER BY</>, merge joins, and <command>CREATE INDEX</>.
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
@ -1847,8 +1870,7 @@ dynamic_library_path = '/usr/local/lib/postgresql:/home/my_project/lib:$libdir'
|
|||||||
behavior you can set this variable to off, but in the long run
|
behavior you can set this variable to off, but in the long run
|
||||||
you are encouraged to change your applications to use the
|
you are encouraged to change your applications to use the
|
||||||
<literal>ONLY</literal> keyword to exclude subtables. See the
|
<literal>ONLY</literal> keyword to exclude subtables. See the
|
||||||
SQL language reference and the <citetitle>User's
|
SQL language reference and the &cite-user; for more information about inheritance.
|
||||||
Guide</citetitle> for more information about inheritance.
|
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
@ -1887,7 +1909,7 @@ dynamic_library_path = '/usr/local/lib/postgresql:/home/my_project/lib:$libdir'
|
|||||||
<para>
|
<para>
|
||||||
Sets the time zone for displaying and interpreting timestamps.
|
Sets the time zone for displaying and interpreting timestamps.
|
||||||
The default is to use whatever the system environment
|
The default is to use whatever the system environment
|
||||||
specifies as the timezone.
|
specifies as the time zone.
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
@ -1901,10 +1923,10 @@ dynamic_library_path = '/usr/local/lib/postgresql:/home/my_project/lib:$libdir'
|
|||||||
<literal><replaceable>expr</> = NULL</literal> (or <literal>NULL
|
<literal><replaceable>expr</> = NULL</literal> (or <literal>NULL
|
||||||
= <replaceable>expr</></literal>) are treated as
|
= <replaceable>expr</></literal>) are treated as
|
||||||
<literal><replaceable>expr</> IS NULL</literal>, that is, they
|
<literal><replaceable>expr</> IS NULL</literal>, that is, they
|
||||||
return true if <replaceable>expr</> evaluates to the NULL value,
|
return true if <replaceable>expr</> evaluates to the null value,
|
||||||
and false otherwise. The correct behavior of
|
and false otherwise. The correct behavior of
|
||||||
<literal><replaceable>expr</> = NULL</literal> is to always
|
<literal><replaceable>expr</> = NULL</literal> is to always
|
||||||
return NULL (unknown). Therefore this option defaults to off.
|
return null (unknown). Therefore this option defaults to off.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
@ -1914,11 +1936,11 @@ dynamic_library_path = '/usr/local/lib/postgresql:/home/my_project/lib:$libdir'
|
|||||||
null values, so if you use that interface to access the database you
|
null values, so if you use that interface to access the database you
|
||||||
might want to turn this option on. Since expressions of the
|
might want to turn this option on. Since expressions of the
|
||||||
form <literal><replaceable>expr</> = NULL</literal> always
|
form <literal><replaceable>expr</> = NULL</literal> always
|
||||||
return NULL (using the correct interpretation) they are not
|
return the null value (using the correct interpretation) they are not
|
||||||
very useful and do not appear often in normal applications, so
|
very useful and do not appear often in normal applications, so
|
||||||
this option does little harm in practice. But new users are
|
this option does little harm in practice. But new users are
|
||||||
frequently confused about the semantics of expressions
|
frequently confused about the semantics of expressions
|
||||||
involving NULL, so this option is not on by default.
|
involving null values, so this option is not on by default.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
@ -1930,8 +1952,7 @@ dynamic_library_path = '/usr/local/lib/postgresql:/home/my_project/lib:$libdir'
|
|||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
Refer to the <citetitle>User's Guide</citetitle> for related
|
Refer to the &cite-user; for related information.
|
||||||
information.
|
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
@ -1941,7 +1962,7 @@ dynamic_library_path = '/usr/local/lib/postgresql:/home/my_project/lib:$libdir'
|
|||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
Specifies the directory of the Unix-domain socket on which the
|
Specifies the directory of the Unix-domain socket on which the
|
||||||
<application>postmaster</application> is to listen for
|
server is to listen for
|
||||||
connections from client applications. The default is normally
|
connections from client applications. The default is normally
|
||||||
<filename>/tmp</filename>, but can be changed at build time.
|
<filename>/tmp</filename>, but can be changed at build time.
|
||||||
</para>
|
</para>
|
||||||
@ -1954,7 +1975,7 @@ dynamic_library_path = '/usr/local/lib/postgresql:/home/my_project/lib:$libdir'
|
|||||||
<para>
|
<para>
|
||||||
Sets the group owner of the Unix domain socket. (The owning
|
Sets the group owner of the Unix domain socket. (The owning
|
||||||
user of the socket is always the user that starts the
|
user of the socket is always the user that starts the
|
||||||
postmaster.) In combination with the option
|
server.) In combination with the option
|
||||||
<option>UNIX_SOCKET_PERMISSIONS</option> this can be used as
|
<option>UNIX_SOCKET_PERMISSIONS</option> this can be used as
|
||||||
an additional access control mechanism for this socket type.
|
an additional access control mechanism for this socket type.
|
||||||
By default this is the empty string, which uses the default
|
By default this is the empty string, which uses the default
|
||||||
@ -1982,7 +2003,7 @@ dynamic_library_path = '/usr/local/lib/postgresql:/home/my_project/lib:$libdir'
|
|||||||
anyone can connect. Reasonable alternatives are
|
anyone can connect. Reasonable alternatives are
|
||||||
<literal>0770</literal> (only user and group, see also under
|
<literal>0770</literal> (only user and group, see also under
|
||||||
<option>UNIX_SOCKET_GROUP</option>) and <literal>0700</literal>
|
<option>UNIX_SOCKET_GROUP</option>) and <literal>0700</literal>
|
||||||
(only user). (Note that actually for a Unix socket, only write
|
(only user). (Note that actually for a Unix domain socket, only write
|
||||||
permission matters and there is no point in setting or revoking
|
permission matters and there is no point in setting or revoking
|
||||||
read or execute permissions.)
|
read or execute permissions.)
|
||||||
</para>
|
</para>
|
||||||
@ -2070,8 +2091,8 @@ dynamic_library_path = '/usr/local/lib/postgresql:/home/my_project/lib:$libdir'
|
|||||||
enough additional transactions may become ready to commit within
|
enough additional transactions may become ready to commit within
|
||||||
the given interval. But the delay is just wasted if no other
|
the given interval. But the delay is just wasted if no other
|
||||||
transactions become ready to commit. Therefore, the delay is
|
transactions become ready to commit. Therefore, the delay is
|
||||||
only performed if at least COMMIT_SIBLINGS other transactions
|
only performed if at least <varname>COMMIT_SIBLINGS</varname> other transactions
|
||||||
are active at the instant that a backend has written its commit
|
are active at the instant that a backend process has written its commit
|
||||||
record.
|
record.
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
@ -2103,7 +2124,7 @@ dynamic_library_path = '/usr/local/lib/postgresql:/home/my_project/lib:$libdir'
|
|||||||
<term><varname>WAL_DEBUG</varname> (<type>integer</type>)</term>
|
<term><varname>WAL_DEBUG</varname> (<type>integer</type>)</term>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
If non-zero, turn on WAL-related debugging output on standard
|
If nonzero, turn on WAL-related debugging output on standard
|
||||||
error.
|
error.
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
@ -2131,104 +2152,108 @@ dynamic_library_path = '/usr/local/lib/postgresql:/home/my_project/lib:$libdir'
|
|||||||
|
|
||||||
|
|
||||||
<sect2 id="runtime-config-short">
|
<sect2 id="runtime-config-short">
|
||||||
<title>Short options</title>
|
<title>Short Options</title>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
For convenience there are also single letter option switches
|
For convenience there are also single letter option switches
|
||||||
available for many parameters. They are described in the following
|
available for many parameters. They are described in <xref
|
||||||
table.
|
linkend="runtime-config-short-table">.
|
||||||
|
</para>
|
||||||
|
|
||||||
<table>
|
<table id="runtime-config-short-table">
|
||||||
<title>Short option key</title>
|
<title>Short option key</title>
|
||||||
<tgroup cols="3">
|
<tgroup cols="2">
|
||||||
<colspec colnum="3" align="center">
|
|
||||||
<thead>
|
<thead>
|
||||||
<row>
|
<row>
|
||||||
<entry>Short option</entry>
|
<entry>Short option</entry>
|
||||||
<entry>Equivalent</entry>
|
<entry>Equivalent</entry>
|
||||||
<entry>Remark</entry>
|
|
||||||
</row>
|
</row>
|
||||||
</thead>
|
</thead>
|
||||||
|
|
||||||
<tbody>
|
<tbody>
|
||||||
<row>
|
<row>
|
||||||
<entry><option>-B <replaceable>x</replaceable></option></entry>
|
<entry><option>-B <replaceable>x</replaceable></option></entry>
|
||||||
<entry><literal>shared_buffers = <replaceable>x</replaceable></></entry>
|
<entry><literal>shared_buffers = <replaceable>x</replaceable></></entry>
|
||||||
<entry></entry>
|
|
||||||
</row>
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry><option>-d <replaceable>x</replaceable></option></entry>
|
<entry><option>-d <replaceable>x</replaceable></option></entry>
|
||||||
<entry><literal>server_min_messages = <replaceable>DEBUGx</replaceable></></entry>
|
<entry><literal>server_min_messages = DEBUG<replaceable>x</replaceable></></entry>
|
||||||
<entry></entry>
|
|
||||||
</row>
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry><option>-F</option></entry>
|
<entry><option>-F</option></entry>
|
||||||
<entry><literal>fsync = off</></entry>
|
<entry><literal>fsync = off</></entry>
|
||||||
<entry></entry>
|
|
||||||
</row>
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry><option>-h <replaceable>x</replaceable></option></entry>
|
<entry><option>-h <replaceable>x</replaceable></option></entry>
|
||||||
<entry><literal>virtual_host = <replaceable>x</replaceable></></entry>
|
<entry><literal>virtual_host = <replaceable>x</replaceable></></entry>
|
||||||
<entry></entry>
|
|
||||||
</row>
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry><option>-i</option></entry>
|
<entry><option>-i</option></entry>
|
||||||
<entry><literal>tcpip_socket = on</></entry>
|
<entry><literal>tcpip_socket = on</></entry>
|
||||||
<entry></entry>
|
|
||||||
</row>
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry><option>-k <replaceable>x</replaceable></option></entry>
|
<entry><option>-k <replaceable>x</replaceable></option></entry>
|
||||||
<entry><literal>unix_socket_directory = <replaceable>x</replaceable></></entry>
|
<entry><literal>unix_socket_directory = <replaceable>x</replaceable></></entry>
|
||||||
<entry></entry>
|
|
||||||
</row>
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry><option>-l</option></entry>
|
<entry><option>-l</option></entry>
|
||||||
<entry><literal>ssl = on</></entry>
|
<entry><literal>ssl = on</></entry>
|
||||||
<entry></entry>
|
|
||||||
</row>
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry><option>-N <replaceable>x</replaceable></option></entry>
|
<entry><option>-N <replaceable>x</replaceable></option></entry>
|
||||||
<entry><literal>max_connections = <replaceable>x</replaceable></></entry>
|
<entry><literal>max_connections = <replaceable>x</replaceable></></entry>
|
||||||
<entry></entry>
|
|
||||||
</row>
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry><option>-p <replaceable>x</replaceable></option></entry>
|
<entry><option>-p <replaceable>x</replaceable></option></entry>
|
||||||
<entry><literal>port = <replaceable>x</replaceable></></entry>
|
<entry><literal>port = <replaceable>x</replaceable></></entry>
|
||||||
<entry></entry>
|
|
||||||
</row>
|
</row>
|
||||||
|
|
||||||
<row>
|
<row>
|
||||||
<entry><option>-fi</option>, <option>-fh</option>, <option>-fm</option>, <option>-fn</option>, <option>-fs</option>, <option>-ft</option></entry>
|
<entry>
|
||||||
<entry><literal>enable_indexscan=off</>, <literal>enable_hashjoin=off</>,
|
<option>-fi</option>, <option>-fh</option>,
|
||||||
<literal>enable_mergejoin=off</>, <literal>enable_nestloop=off</>, <literal>enable_seqscan=off</>,
|
<option>-fm</option>, <option>-fn</option>,
|
||||||
<literal>enable_tidscan=off</></entry>
|
<option>-fs</option>, <option>-ft</option><footnote
|
||||||
<entry>*</entry>
|
id="fn.runtime-config-short">
|
||||||
|
<para>
|
||||||
|
For historical reasons, these options must be passed to
|
||||||
|
the individual backend process via the <option>-o</option>
|
||||||
|
postmaster option, for example,
|
||||||
|
<screen>
|
||||||
|
$ <userinput>postmaster -o '-S 1024 -s'</userinput>
|
||||||
|
</screen>
|
||||||
|
or via <envar>PGOPTIONS</envar> from the client side, as
|
||||||
|
explained above.
|
||||||
|
</para>
|
||||||
|
</footnote>
|
||||||
|
</entry>
|
||||||
|
<entry>
|
||||||
|
<literal>enable_indexscan=off</>,
|
||||||
|
<literal>enable_hashjoin=off</>,
|
||||||
|
<literal>enable_mergejoin=off</>,
|
||||||
|
<literal>enable_nestloop=off</>,
|
||||||
|
<literal>enable_seqscan=off</>,
|
||||||
|
<literal>enable_tidscan=off</>
|
||||||
|
</entry>
|
||||||
</row>
|
</row>
|
||||||
|
|
||||||
<row>
|
<row>
|
||||||
<entry><option>-S <replaceable>x</replaceable></option></entry>
|
<entry><option>-s</option><footnoteref linkend="fn.runtime-config-short"></entry>
|
||||||
<entry><literal>sort_mem = <replaceable>x</replaceable></></entry>
|
|
||||||
<entry>*</entry>
|
|
||||||
</row>
|
|
||||||
<row>
|
|
||||||
<entry><option>-s</option></entry>
|
|
||||||
<entry><literal>show_statement_stats = on</></entry>
|
<entry><literal>show_statement_stats = on</></entry>
|
||||||
<entry>*</entry>
|
|
||||||
</row>
|
</row>
|
||||||
|
|
||||||
<row>
|
<row>
|
||||||
<entry><option>-tpa</option>, <option>-tpl</option>, <option>-te</option></entry>
|
<entry><option>-S <replaceable>x</replaceable></option><footnoteref linkend="fn.runtime-config-short">
|
||||||
|
</entry>
|
||||||
|
<entry><literal>sort_mem = <replaceable>x</replaceable></></entry>
|
||||||
|
</row>
|
||||||
|
|
||||||
|
<row>
|
||||||
|
<entry><option>-tpa</option>, <option>-tpl</option>, <option>-te</option><footnoteref linkend="fn.runtime-config-short"></entry>
|
||||||
<entry><literal>show_parser_stats=on</>, <literal>show_planner_stats=on</>, <literal>show_executor_stats=on</></entry>
|
<entry><literal>show_parser_stats=on</>, <literal>show_planner_stats=on</>, <literal>show_executor_stats=on</></entry>
|
||||||
<entry>*</entry>
|
|
||||||
</row>
|
</row>
|
||||||
</tbody>
|
</tbody>
|
||||||
</tgroup>
|
</tgroup>
|
||||||
</table>
|
</table>
|
||||||
For historical reasons, options marked <quote>*</quote> must be
|
|
||||||
passed to the individual backend process via the
|
|
||||||
<option>-o</option> postmaster option, for example,
|
|
||||||
<screen>
|
|
||||||
$ <userinput>postmaster -o '-S 1024 -s'</userinput>
|
|
||||||
</screen>
|
|
||||||
or via <envar>PGOPTIONS</envar> from the client side, as explained
|
|
||||||
above.
|
|
||||||
</para>
|
|
||||||
|
|
||||||
</sect2>
|
</sect2>
|
||||||
</sect1>
|
</sect1>
|
||||||
@ -2305,7 +2330,7 @@ $ <userinput>postmaster -o '-S 1024 -s'</userinput>
|
|||||||
<row>
|
<row>
|
||||||
<entry><varname>SHMMAX</></>
|
<entry><varname>SHMMAX</></>
|
||||||
<entry>Maximum size of shared memory segment (bytes)</>
|
<entry>Maximum size of shared memory segment (bytes)</>
|
||||||
<entry>250kB + 8.2kB * <varname>shared_buffers</> + 14.2kB * <varname>max_connections</> or infinity</entry>
|
<entry>250kB + 8.2 kB * <varname>shared_buffers</> + 14.2 kB * <varname>max_connections</> or infinity</entry>
|
||||||
</row>
|
</row>
|
||||||
|
|
||||||
<row>
|
<row>
|
||||||
@ -2453,7 +2478,7 @@ $ <userinput>postmaster -o '-S 1024 -s'</userinput>
|
|||||||
mind that shared memory is not pageable; it is locked in RAM.
|
mind that shared memory is not pageable; it is locked in RAM.
|
||||||
To increase the number of shared buffers supported by the
|
To increase the number of shared buffers supported by the
|
||||||
postmaster, add the following to your kernel configuration
|
postmaster, add the following to your kernel configuration
|
||||||
file. A <varname>SHMALL</> value of 1024 represents 4MB of
|
file. A <varname>SHMALL</> value of 1024 represents 4 MB of
|
||||||
shared memory. The following increases the maximum shared
|
shared memory. The following increases the maximum shared
|
||||||
memory area to 32 MB:
|
memory area to 32 MB:
|
||||||
<programlisting>
|
<programlisting>
|
||||||
@ -2466,7 +2491,7 @@ options "SHMMAX=\(SHMALL*PAGE_SIZE\)"
|
|||||||
<para>
|
<para>
|
||||||
For those running 4.1 or later, just make the above changes,
|
For those running 4.1 or later, just make the above changes,
|
||||||
recompile the kernel, and reboot. For those running earlier
|
recompile the kernel, and reboot. For those running earlier
|
||||||
releases, use <application>bpatch</> to find the
|
releases, use <command>bpatch</> to find the
|
||||||
<varname>sysptsize</> value in the current kernel. This is
|
<varname>sysptsize</> value in the current kernel. This is
|
||||||
computed dynamically at boot time.
|
computed dynamically at boot time.
|
||||||
<screen>
|
<screen>
|
||||||
@ -2812,7 +2837,7 @@ default:\
|
|||||||
|
|
||||||
|
|
||||||
<sect1 id="postmaster-shutdown">
|
<sect1 id="postmaster-shutdown">
|
||||||
<title>Shutting down the server</title>
|
<title>Shutting Down the Server</title>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
There are several ways to shut down the database server. You control
|
There are several ways to shut down the database server. You control
|
||||||
@ -2903,14 +2928,16 @@ $ <userinput>kill -INT `head -1 /usr/local/pgsql/data/postmaster.pid`</userinput
|
|||||||
|
|
||||||
<para>
|
<para>
|
||||||
With SSL support compiled in, the <productname>PostgreSQL</> server
|
With SSL support compiled in, the <productname>PostgreSQL</> server
|
||||||
can be started with the argument <option>-l</> (ell) to enable
|
can be started with SSL support by setting the parameter
|
||||||
SSL connections. When starting in SSL mode, the server will look
|
<varname>ssl</varname> to on in
|
||||||
for the files <filename>server.key</> and <filename>server.crt</> in
|
<filename>postgresql.conf</filename>. When starting in SSL mode,
|
||||||
the data directory. These files should contain the server private key
|
the server will look for the files <filename>server.key</> and
|
||||||
and certificate respectively. These files must be set up correctly
|
<filename>server.crt</> in the data directory. These files should
|
||||||
before an SSL-enabled server can start. If the private key is protected
|
contain the server private key and certificate respectively. These
|
||||||
with a passphrase, the server will prompt for the passphrase and will
|
files must be set up correctly before an SSL-enabled server can
|
||||||
not start until it has been entered.
|
start. If the private key is protected with a passphrase, the
|
||||||
|
server will prompt for the passphrase and will not start until it
|
||||||
|
has been entered.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
@ -2924,19 +2951,18 @@ $ <userinput>kill -INT `head -1 /usr/local/pgsql/data/postmaster.pid`</userinput
|
|||||||
For details on how to create your server private key and certificate,
|
For details on how to create your server private key and certificate,
|
||||||
refer to the <productname>OpenSSL</> documentation. A simple
|
refer to the <productname>OpenSSL</> documentation. A simple
|
||||||
self-signed certificate can be used to get started for testing, but a
|
self-signed certificate can be used to get started for testing, but a
|
||||||
certificate signed by a <acronym>CA</> (either one of the global
|
certificate signed by a certificate authority (<acronym>CA</>) (either one of the global
|
||||||
<acronym>CAs</> or a local one) should be used in production so the
|
<acronym>CAs</> or a local one) should be used in production so the
|
||||||
client can verify the server's identity. To create a quick
|
client can verify the server's identity. To create a quick
|
||||||
self-signed certificate, use the following
|
self-signed certificate, use the following
|
||||||
<productname>OpenSSL</productname> command:
|
<productname>OpenSSL</productname> command:
|
||||||
<programlisting>
|
<programlisting>
|
||||||
cd <replaceable>$PGDATA</replaceable>
|
|
||||||
openssl req -new -text -out server.req
|
openssl req -new -text -out server.req
|
||||||
</programlisting>
|
</programlisting>
|
||||||
Fill out the information that <command>openssl</> asks for. Make sure
|
Fill out the information that <command>openssl</> asks for. Make sure
|
||||||
that you enter the local host name as Common Name; the challenge
|
that you enter the local host name as Common Name; the challenge
|
||||||
password can be left blank. The script will generate a key that is
|
password can be left blank. The script will generate a key that is
|
||||||
passphrase protected; it will not accept a pass phrase that is less
|
passphrase protected; it will not accept a passphrase that is less
|
||||||
than four characters long. To remove the passphrase (as you must if
|
than four characters long. To remove the passphrase (as you must if
|
||||||
you want automatic start-up of the server), run the commands
|
you want automatic start-up of the server), run the commands
|
||||||
<programlisting>
|
<programlisting>
|
||||||
@ -2954,7 +2980,7 @@ chmod og-rwx server.key
|
|||||||
</sect1>
|
</sect1>
|
||||||
|
|
||||||
<sect1 id="ssh-tunnels">
|
<sect1 id="ssh-tunnels">
|
||||||
<title>Secure TCP/IP Connections with <application>SSH</application> tunnels</title>
|
<title>Secure TCP/IP Connections with <application>SSH</application> Tunnels</title>
|
||||||
|
|
||||||
<indexterm zone="ssh-tunnels">
|
<indexterm zone="ssh-tunnels">
|
||||||
<primary>ssh</primary>
|
<primary>ssh</primary>
|
||||||
@ -2970,20 +2996,20 @@ chmod og-rwx server.key
|
|||||||
</note>
|
</note>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
One can use <productname>ssh</productname> to encrypt the network
|
One can use <application>SSH</application> to encrypt the network
|
||||||
connection between clients and a
|
connection between clients and a
|
||||||
<productname>PostgreSQL</productname> server. Done properly, this
|
<productname>PostgreSQL</productname> server. Done properly, this
|
||||||
should lead to an adequately secure network connection.
|
provides an adequately secure network connection.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
First make sure that an <application>ssh</application> server is
|
First make sure that an <application>SSH</application> server is
|
||||||
running properly on the same machine as
|
running properly on the same machine as
|
||||||
<productname>PostgreSQL</productname> and that you can log in using
|
<productname>PostgreSQL</productname> and that you can log in using
|
||||||
<command>ssh</command> as some user. Then you can establish a secure
|
<command>ssh</command> as some user. Then you can establish a secure
|
||||||
tunnel with a command like this from the client machine:
|
tunnel with a command like this from the client machine:
|
||||||
<programlisting>
|
<programlisting>
|
||||||
$ <userinput>ssh -L 3333:foo.com:5432 joe@foo.com</userinput>
|
ssh -L 3333:foo.com:5432 joe@foo.com
|
||||||
</programlisting>
|
</programlisting>
|
||||||
The first number in the <option>-L</option> argument, 3333, is the
|
The first number in the <option>-L</option> argument, 3333, is the
|
||||||
port number of your end of the tunnel; it can be chosen freely. The
|
port number of your end of the tunnel; it can be chosen freely. The
|
||||||
@ -3006,7 +3032,7 @@ psql -h localhost -p 3333 template1
|
|||||||
|
|
||||||
<tip>
|
<tip>
|
||||||
<para>
|
<para>
|
||||||
Several other products exist that can provide secure tunnels using
|
Several other applications exist that can provide secure tunnels using
|
||||||
a procedure similar in concept to the one just described.
|
a procedure similar in concept to the one just described.
|
||||||
</para>
|
</para>
|
||||||
</tip>
|
</tip>
|
||||||
|
@ -1,5 +1,5 @@
|
|||||||
<!--
|
<!--
|
||||||
$Header: /cvsroot/pgsql/doc/src/sgml/start.sgml,v 1.26 2002/10/24 17:48:54 petere Exp $
|
$Header: /cvsroot/pgsql/doc/src/sgml/start.sgml,v 1.27 2002/11/11 20:14:04 petere Exp $
|
||||||
-->
|
-->
|
||||||
|
|
||||||
<chapter id="tutorial-start">
|
<chapter id="tutorial-start">
|
||||||
@ -281,10 +281,10 @@ createdb: database creation failed
|
|||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
Using an existing graphical frontend tool like
|
Using an existing graphical frontend tool like
|
||||||
<application>PgAccess</application> or
|
<application>PgAccess</application> or an office suite with
|
||||||
<application>ApplixWare</application> (via
|
<acronym>ODBC</acronym> support to create and manipulate a
|
||||||
<acronym>ODBC</acronym>) to create and manipulate a database.
|
database. These possibilities are not covered in this
|
||||||
These possibilities are not covered in this tutorial.
|
tutorial.
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
|
@ -1,5 +1,5 @@
|
|||||||
<!--
|
<!--
|
||||||
$Header: /cvsroot/pgsql/doc/src/sgml/syntax.sgml,v 1.72 2002/10/24 17:48:54 petere Exp $
|
$Header: /cvsroot/pgsql/doc/src/sgml/syntax.sgml,v 1.73 2002/11/11 20:14:04 petere Exp $
|
||||||
-->
|
-->
|
||||||
|
|
||||||
<chapter id="sql-syntax">
|
<chapter id="sql-syntax">
|
||||||
@ -121,7 +121,7 @@ INSERT INTO MY_TABLE VALUES (3, 'hi there');
|
|||||||
characters of an identifier; longer names can be written in
|
characters of an identifier; longer names can be written in
|
||||||
commands, but they will be truncated. By default,
|
commands, but they will be truncated. By default,
|
||||||
<symbol>NAMEDATALEN</symbol> is 64 so the maximum identifier length
|
<symbol>NAMEDATALEN</symbol> is 64 so the maximum identifier length
|
||||||
is 63 (but at the time the system is built,
|
is 63 (but at the time PostgreSQL is built,
|
||||||
<symbol>NAMEDATALEN</symbol> can be changed in
|
<symbol>NAMEDATALEN</symbol> can be changed in
|
||||||
<filename>src/include/postgres_ext.h</filename>).
|
<filename>src/include/postgres_ext.h</filename>).
|
||||||
</para>
|
</para>
|
||||||
@ -170,8 +170,9 @@ UPDATE "my_table" SET "a" = 5;
|
|||||||
|
|
||||||
<para>
|
<para>
|
||||||
Quoted identifiers can contain any character other than a double
|
Quoted identifiers can contain any character other than a double
|
||||||
quote itself. This allows constructing table or column names that
|
quote itself. To include a double quote, write two double quotes.
|
||||||
would otherwise not be possible, such as ones containing spaces or
|
This allows constructing table or column names that would
|
||||||
|
otherwise not be possible, such as ones containing spaces or
|
||||||
ampersands. The length limitation still applies.
|
ampersands. The length limitation still applies.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
@ -272,7 +273,7 @@ SELECT 'foobar';
|
|||||||
SELECT 'foo' 'bar';
|
SELECT 'foo' 'bar';
|
||||||
</programlisting>
|
</programlisting>
|
||||||
is not valid syntax. (This slightly bizarre behavior is specified
|
is not valid syntax. (This slightly bizarre behavior is specified
|
||||||
by <acronym>SQL9x</acronym>; <productname>PostgreSQL</productname> is
|
by <acronym>SQL</acronym>; <productname>PostgreSQL</productname> is
|
||||||
following the standard.)
|
following the standard.)
|
||||||
</para>
|
</para>
|
||||||
</sect3>
|
</sect3>
|
||||||
@ -298,7 +299,7 @@ SELECT 'foo' 'bar';
|
|||||||
Alternatively, bit-string constants can be specified in hexadecimal
|
Alternatively, bit-string constants can be specified in hexadecimal
|
||||||
notation, using a leading <literal>X</literal> (upper or lower case),
|
notation, using a leading <literal>X</literal> (upper or lower case),
|
||||||
e.g., <literal>X'1FF'</literal>. This notation is equivalent to
|
e.g., <literal>X'1FF'</literal>. This notation is equivalent to
|
||||||
a bit-string constant with four binary digits for each hex digit.
|
a bit-string constant with four binary digits for each hexadecimal digit.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
@ -328,7 +329,7 @@ SELECT 'foo' 'bar';
|
|||||||
decimal point, if one is used. At least one digit must follow the
|
decimal point, if one is used. At least one digit must follow the
|
||||||
exponent marker (<literal>e</literal>), if one is present.
|
exponent marker (<literal>e</literal>), if one is present.
|
||||||
There may not be any spaces or other characters embedded in the
|
There may not be any spaces or other characters embedded in the
|
||||||
constant. Notice that any leading plus or minus sign is not actually
|
constant. Note that any leading plus or minus sign is not actually
|
||||||
considered part of the constant; it is an operator applied to the
|
considered part of the constant; it is an operator applied to the
|
||||||
constant.
|
constant.
|
||||||
</para>
|
</para>
|
||||||
@ -650,13 +651,16 @@ CAST ( '<replaceable>string</replaceable>' AS <replaceable>type</replaceable> )
|
|||||||
</indexterm>
|
</indexterm>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
The precedence and associativity of the operators is hard-wired
|
<xref linkend="sql-precedence-table"> shows the precedence and
|
||||||
into the parser. Most operators have the same precedence and are
|
associativity of the operators in PostgreSQL. Most operators have
|
||||||
left-associative. This may lead to non-intuitive behavior; for
|
the same precedence and are left-associative. The precedence and
|
||||||
example the Boolean operators <literal><</> and <literal>></> have a different
|
associativity of the operators is hard-wired into the parser.
|
||||||
precedence than the Boolean operators <literal><=</> and <literal>>=</>. Also,
|
This may lead to non-intuitive behavior; for example the Boolean
|
||||||
you will sometimes need to add parentheses when using combinations
|
operators <literal><</> and <literal>></> have a different
|
||||||
of binary and unary operators. For instance
|
precedence than the Boolean operators <literal><=</> and
|
||||||
|
<literal>>=</>. Also, you will sometimes need to add
|
||||||
|
parentheses when using combinations of binary and unary operators.
|
||||||
|
For instance
|
||||||
<programlisting>
|
<programlisting>
|
||||||
SELECT 5 ! - 6;
|
SELECT 5 ! - 6;
|
||||||
</programlisting>
|
</programlisting>
|
||||||
@ -673,7 +677,7 @@ SELECT (5 !) - 6;
|
|||||||
This is the price one pays for extensibility.
|
This is the price one pays for extensibility.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<table tocentry="1">
|
<table id="sql-precedence-table">
|
||||||
<title>Operator Precedence (decreasing)</title>
|
<title>Operator Precedence (decreasing)</title>
|
||||||
|
|
||||||
<tgroup cols="3">
|
<tgroup cols="3">
|
||||||
@ -825,7 +829,7 @@ SELECT (5 !) - 6;
|
|||||||
SELECT 3 OPERATOR(pg_catalog.+) 4;
|
SELECT 3 OPERATOR(pg_catalog.+) 4;
|
||||||
</programlisting>
|
</programlisting>
|
||||||
the <literal>OPERATOR</> construct is taken to have the default precedence
|
the <literal>OPERATOR</> construct is taken to have the default precedence
|
||||||
shown above for <quote>any other</> operator. This is true no matter
|
shown in <xref linkend="sql-precedence-table"> for <quote>any other</> operator. This is true no matter
|
||||||
which specific operator name appears inside <literal>OPERATOR()</>.
|
which specific operator name appears inside <literal>OPERATOR()</>.
|
||||||
</para>
|
</para>
|
||||||
</sect2>
|
</sect2>
|
||||||
@ -901,9 +905,8 @@ SELECT 3 OPERATOR(pg_catalog.+) 4;
|
|||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<synopsis>( <replaceable>expression</replaceable> )</synopsis>
|
|
||||||
<para>
|
<para>
|
||||||
Parentheses are used to group subexpressions and override precedence.
|
Another value expression in parentheses, useful to group subexpressions and override precedence.
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</itemizedlist>
|
</itemizedlist>
|
||||||
@ -928,21 +931,30 @@ SELECT 3 OPERATOR(pg_catalog.+) 4;
|
|||||||
<title>Column References</title>
|
<title>Column References</title>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
A column can be referenced in the form:
|
A column can be referenced in the form
|
||||||
<synopsis>
|
<synopsis>
|
||||||
<replaceable>correlation</replaceable>.<replaceable>columnname</replaceable> `['<replaceable>subscript</replaceable>`]'
|
<replaceable>correlation</replaceable>.<replaceable>columnname</replaceable>
|
||||||
</synopsis>
|
</synopsis>
|
||||||
|
or
|
||||||
|
<synopsis>
|
||||||
|
<replaceable>correlation</replaceable>.<replaceable>columnname</replaceable>[<replaceable>subscript</replaceable>]
|
||||||
|
</synopsis>
|
||||||
|
(Here, the brackets <literal>[ ]</literal> are meant to appear literally.)
|
||||||
|
</para>
|
||||||
|
|
||||||
|
<para>
|
||||||
<replaceable>correlation</replaceable> is the name of a
|
<replaceable>correlation</replaceable> is the name of a
|
||||||
table (possibly qualified), or an alias for a table defined by means of a
|
table (possibly qualified), or an alias for a table defined by means of a
|
||||||
FROM clause, or
|
<literal>FROM</literal> clause, or
|
||||||
the key words <literal>NEW</literal> or <literal>OLD</literal>.
|
the key words <literal>NEW</literal> or <literal>OLD</literal>.
|
||||||
(NEW and OLD can only appear in rules,
|
(<literal>NEW</literal> and <literal>OLD</literal> can only appear in rewrite rules,
|
||||||
while other correlation names can be used in any SQL statement.)
|
while other correlation names can be used in any SQL statement.)
|
||||||
The correlation name and separating dot may be omitted if the column name
|
The correlation name and separating dot may be omitted if the column name
|
||||||
is unique
|
is unique across all the tables being used in the current query. (See also <xref linkend="queries">.)
|
||||||
across all the tables being used in the current query. If
|
</para>
|
||||||
<replaceable>column</replaceable> is of an array type, then the
|
|
||||||
|
<para>
|
||||||
|
If <replaceable>column</replaceable> is of an array type, then the
|
||||||
optional <replaceable>subscript</replaceable> selects a specific
|
optional <replaceable>subscript</replaceable> selects a specific
|
||||||
element or elements in the array. If no subscript is provided, then the
|
element or elements in the array. If no subscript is provided, then the
|
||||||
whole array is selected. (See <xref linkend="arrays"> for more about
|
whole array is selected. (See <xref linkend="arrays"> for more about
|
||||||
@ -968,7 +980,7 @@ $<replaceable>number</replaceable>
|
|||||||
<function>dept</function>, as
|
<function>dept</function>, as
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
CREATE FUNCTION dept (text) RETURNS dept
|
CREATE FUNCTION dept(text) RETURNS dept
|
||||||
AS 'SELECT * FROM dept WHERE name = $1'
|
AS 'SELECT * FROM dept WHERE name = $1'
|
||||||
LANGUAGE SQL;
|
LANGUAGE SQL;
|
||||||
</programlisting>
|
</programlisting>
|
||||||
@ -993,7 +1005,7 @@ CREATE FUNCTION dept (text) RETURNS dept
|
|||||||
keywords <token>AND</token>, <token>OR</token>, and
|
keywords <token>AND</token>, <token>OR</token>, and
|
||||||
<token>NOT</token>, or is a qualified operator name
|
<token>NOT</token>, or is a qualified operator name
|
||||||
<synopsis>
|
<synopsis>
|
||||||
<literal>OPERATOR(</><replaceable>schema</><literal>.</><replaceable>operatorname</><literal>)</>
|
<literal>OPERATOR(</><replaceable>schema</><literal>.</><replaceable>operatorname</><literal>)</>
|
||||||
</synopsis>
|
</synopsis>
|
||||||
Which particular operators exist and whether
|
Which particular operators exist and whether
|
||||||
they are unary or binary depends on what operators have been
|
they are unary or binary depends on what operators have been
|
||||||
@ -1042,12 +1054,12 @@ sqrt(2)
|
|||||||
output value, such as the sum or average of the inputs. The
|
output value, such as the sum or average of the inputs. The
|
||||||
syntax of an aggregate expression is one of the following:
|
syntax of an aggregate expression is one of the following:
|
||||||
|
|
||||||
<simplelist>
|
<synopsis>
|
||||||
<member><replaceable>aggregate_name</replaceable> (<replaceable>expression</replaceable>)</member>
|
<replaceable>aggregate_name</replaceable> (<replaceable>expression</replaceable>)
|
||||||
<member><replaceable>aggregate_name</replaceable> (ALL <replaceable>expression</replaceable>)</member>
|
<replaceable>aggregate_name</replaceable> (ALL <replaceable>expression</replaceable>)
|
||||||
<member><replaceable>aggregate_name</replaceable> (DISTINCT <replaceable>expression</replaceable>)</member>
|
<replaceable>aggregate_name</replaceable> (DISTINCT <replaceable>expression</replaceable>)
|
||||||
<member><replaceable>aggregate_name</replaceable> ( * )</member>
|
<replaceable>aggregate_name</replaceable> ( * )
|
||||||
</simplelist>
|
</synopsis>
|
||||||
|
|
||||||
where <replaceable>aggregate_name</replaceable> is a previously
|
where <replaceable>aggregate_name</replaceable> is a previously
|
||||||
defined aggregate (possibly a qualified name), and
|
defined aggregate (possibly a qualified name), and
|
||||||
@ -1101,7 +1113,7 @@ sqrt(2)
|
|||||||
CAST ( <replaceable>expression</replaceable> AS <replaceable>type</replaceable> )
|
CAST ( <replaceable>expression</replaceable> AS <replaceable>type</replaceable> )
|
||||||
<replaceable>expression</replaceable>::<replaceable>type</replaceable>
|
<replaceable>expression</replaceable>::<replaceable>type</replaceable>
|
||||||
</synopsis>
|
</synopsis>
|
||||||
The <literal>CAST</> syntax conforms to SQL92; the syntax with
|
The <literal>CAST</> syntax conforms to SQL; the syntax with
|
||||||
<literal>::</literal> is historical <productname>PostgreSQL</productname>
|
<literal>::</literal> is historical <productname>PostgreSQL</productname>
|
||||||
usage.
|
usage.
|
||||||
</para>
|
</para>
|
||||||
@ -1123,8 +1135,8 @@ CAST ( <replaceable>expression</replaceable> AS <replaceable>type</replaceable>
|
|||||||
to the type that a value expression must produce (for example, when it is
|
to the type that a value expression must produce (for example, when it is
|
||||||
assigned to a table column); the system will automatically apply a
|
assigned to a table column); the system will automatically apply a
|
||||||
type cast in such cases. However, automatic casting is only done for
|
type cast in such cases. However, automatic casting is only done for
|
||||||
cast functions that are marked <quote>OK to apply implicitly</>
|
casts that are marked <quote>OK to apply implicitly</>
|
||||||
in the system catalogs. Other cast functions must be invoked with
|
in the system catalogs. Other casts must be invoked with
|
||||||
explicit casting syntax. This restriction is intended to prevent
|
explicit casting syntax. This restriction is intended to prevent
|
||||||
surprising conversions from being applied silently.
|
surprising conversions from being applied silently.
|
||||||
</para>
|
</para>
|
||||||
@ -1143,6 +1155,13 @@ CAST ( <replaceable>expression</replaceable> AS <replaceable>type</replaceable>
|
|||||||
double-quoted, because of syntactic conflicts. Therefore, the use of
|
double-quoted, because of syntactic conflicts. Therefore, the use of
|
||||||
the function-like cast syntax leads to inconsistencies and should
|
the function-like cast syntax leads to inconsistencies and should
|
||||||
probably be avoided in new applications.
|
probably be avoided in new applications.
|
||||||
|
|
||||||
|
(The function-like syntax is in fact just a function call. When
|
||||||
|
one of the two standard cast syntaxes is used to do a run-time
|
||||||
|
conversion, it will internally invoke a registered function to
|
||||||
|
perform the conversion. By convention, these conversion functions
|
||||||
|
have the same name as their output type, but this is not something
|
||||||
|
that a portable application should rely on.)
|
||||||
</para>
|
</para>
|
||||||
</sect2>
|
</sect2>
|
||||||
|
|
||||||
@ -1151,8 +1170,9 @@ CAST ( <replaceable>expression</replaceable> AS <replaceable>type</replaceable>
|
|||||||
|
|
||||||
<para>
|
<para>
|
||||||
A scalar subquery is an ordinary
|
A scalar subquery is an ordinary
|
||||||
<command>SELECT</command> in parentheses that returns exactly one
|
<command>SELECT</command> query in parentheses that returns exactly one
|
||||||
row with one column. The <command>SELECT</command> query is executed
|
row with one column. (See <xref linkend="queries"> for information about writing queries.)
|
||||||
|
The <command>SELECT</command> query is executed
|
||||||
and the single returned value is used in the surrounding value expression.
|
and the single returned value is used in the surrounding value expression.
|
||||||
It is an error to use a query that
|
It is an error to use a query that
|
||||||
returns more than one row or more than one column as a scalar subquery.
|
returns more than one row or more than one column as a scalar subquery.
|
||||||
@ -1168,7 +1188,7 @@ CAST ( <replaceable>expression</replaceable> AS <replaceable>type</replaceable>
|
|||||||
state:
|
state:
|
||||||
<programlisting>
|
<programlisting>
|
||||||
SELECT name, (SELECT max(pop) FROM cities WHERE cities.state = states.name)
|
SELECT name, (SELECT max(pop) FROM cities WHERE cities.state = states.name)
|
||||||
FROM states;
|
FROM states;
|
||||||
</programlisting>
|
</programlisting>
|
||||||
</para>
|
</para>
|
||||||
</sect2>
|
</sect2>
|
||||||
@ -1202,25 +1222,26 @@ SELECT somefunc() OR true;
|
|||||||
<para>
|
<para>
|
||||||
As a consequence, it is unwise to use functions with side effects
|
As a consequence, it is unwise to use functions with side effects
|
||||||
as part of complex expressions. It is particularly dangerous to
|
as part of complex expressions. It is particularly dangerous to
|
||||||
rely on side effects or evaluation order in WHERE and HAVING clauses,
|
rely on side effects or evaluation order in <literal>WHERE</> and <literal>HAVING</> clauses,
|
||||||
since those clauses are extensively reprocessed as part of
|
since those clauses are extensively reprocessed as part of
|
||||||
developing an execution plan. Boolean
|
developing an execution plan. Boolean
|
||||||
expressions (AND/OR/NOT combinations) in those clauses may be reorganized
|
expressions (<literal>AND</>/<literal>OR</>/<literal>NOT</> combinations) in those clauses may be reorganized
|
||||||
in any manner allowed by the laws of Boolean algebra.
|
in any manner allowed by the laws of Boolean algebra.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
When it is essential to force evaluation order, a CASE construct may
|
When it is essential to force evaluation order, a <literal>CASE</>
|
||||||
be used. For example, this is an untrustworthy way of trying to
|
construct (see <xref linkend="functions-conditional">) may be
|
||||||
avoid division by zero in a WHERE clause:
|
used. For example, this is an untrustworthy way of trying to
|
||||||
|
avoid division by zero in a <literal>WHERE</> clause:
|
||||||
<programlisting>
|
<programlisting>
|
||||||
SELECT ... WHERE x <> 0 AND y/x > 1.5;
|
SELECT ... WHERE x <> 0 AND y/x > 1.5;
|
||||||
</programlisting>
|
</programlisting>
|
||||||
but this is safe:
|
But this is safe:
|
||||||
<programlisting>
|
<programlisting>
|
||||||
SELECT ... WHERE CASE WHEN x <> 0 THEN y/x > 1.5 ELSE false END;
|
SELECT ... WHERE CASE WHEN x <> 0 THEN y/x > 1.5 ELSE false END;
|
||||||
</programlisting>
|
</programlisting>
|
||||||
A CASE construct used in this fashion will defeat optimization attempts,
|
A <literal>CASE</> construct used in this fashion will defeat optimization attempts,
|
||||||
so it should only be done when necessary.
|
so it should only be done when necessary.
|
||||||
</para>
|
</para>
|
||||||
</sect2>
|
</sect2>
|
||||||
|
@ -1,9 +1,6 @@
|
|||||||
<chapter Id="typeconv">
|
<chapter Id="typeconv">
|
||||||
<title>Type Conversion</title>
|
<title>Type Conversion</title>
|
||||||
|
|
||||||
<sect1 id="typeconv-intro">
|
|
||||||
<title>Introduction</title>
|
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
<acronym>SQL</acronym> queries can, intentionally or not, require
|
<acronym>SQL</acronym> queries can, intentionally or not, require
|
||||||
mixing of different data types in the same expression.
|
mixing of different data types in the same expression.
|
||||||
@ -29,10 +26,9 @@ operators.
|
|||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
The <citetitle>Programmer's Guide</citetitle> has more details on the exact algorithms used for
|
The &cite-programmer; has more details on the exact algorithms used for
|
||||||
implicit type conversion and coercion.
|
implicit type conversion and coercion.
|
||||||
</para>
|
</para>
|
||||||
</sect1>
|
|
||||||
|
|
||||||
<sect1 id="typeconv-overview">
|
<sect1 id="typeconv-overview">
|
||||||
<title>Overview</title>
|
<title>Overview</title>
|
||||||
@ -41,7 +37,7 @@ implicit type conversion and coercion.
|
|||||||
<acronym>SQL</acronym> is a strongly typed language. That is, every data item
|
<acronym>SQL</acronym> is a strongly typed language. That is, every data item
|
||||||
has an associated data type which determines its behavior and allowed usage.
|
has an associated data type which determines its behavior and allowed usage.
|
||||||
<productname>PostgreSQL</productname> has an extensible type system that is
|
<productname>PostgreSQL</productname> has an extensible type system that is
|
||||||
much more general and flexible than other <acronym>RDBMS</acronym> implementations.
|
much more general and flexible than other <acronym>SQL</acronym> implementations.
|
||||||
Hence, most type conversion behavior in <productname>PostgreSQL</productname>
|
Hence, most type conversion behavior in <productname>PostgreSQL</productname>
|
||||||
should be governed by general rules rather than by <foreignphrase>ad hoc</> heuristics, to allow
|
should be governed by general rules rather than by <foreignphrase>ad hoc</> heuristics, to allow
|
||||||
mixed-type expressions to be meaningful even with user-defined types.
|
mixed-type expressions to be meaningful even with user-defined types.
|
||||||
@ -142,13 +138,13 @@ conventions for the <acronym>SQL</acronym> standard native types such as
|
|||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
The <productname>PostgreSQL</productname> parser uses the convention that all
|
The system catalogs store information about which conversions, called
|
||||||
type conversion functions take a single argument of the source type and are
|
<firstterm>casts</firstterm>, between data types are valid, and how to
|
||||||
named with the same name as the target type. Any function meeting these
|
perform those conversions. Additional casts can be added by the user
|
||||||
criteria is considered to be a valid conversion function, and may be used
|
with the <command>CREATE CAST</command> command. (This is usually
|
||||||
by the parser as such. This simple assumption gives the parser the power
|
done in conjunction with defining new data types. The set of casts
|
||||||
to explore type conversion possibilities without hardcoding, allowing
|
between the built-in types has been carefully crafted and should not
|
||||||
extended user-defined types to use these same features transparently.
|
be altered.)
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
@ -169,7 +165,7 @@ types.
|
|||||||
<para>
|
<para>
|
||||||
All type conversion rules are designed with several principles in mind:
|
All type conversion rules are designed with several principles in mind:
|
||||||
|
|
||||||
<itemizedlist mark="bullet" spacing="compact">
|
<itemizedlist>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
Implicit conversions should never have surprising or unpredictable outcomes.
|
Implicit conversions should never have surprising or unpredictable outcomes.
|
||||||
|
@ -1,5 +1,5 @@
|
|||||||
<!--
|
<!--
|
||||||
$Header: /cvsroot/pgsql/doc/src/sgml/user-manag.sgml,v 1.17 2002/10/24 17:48:54 petere Exp $
|
$Header: /cvsroot/pgsql/doc/src/sgml/user-manag.sgml,v 1.18 2002/11/11 20:14:04 petere Exp $
|
||||||
-->
|
-->
|
||||||
|
|
||||||
<chapter id="user-manag">
|
<chapter id="user-manag">
|
||||||
@ -129,7 +129,7 @@ dropuser <replaceable>name</replaceable>
|
|||||||
<para>
|
<para>
|
||||||
A password is only significant if the client authentication
|
A password is only significant if the client authentication
|
||||||
method requires the user to supply a password when connecting
|
method requires the user to supply a password when connecting
|
||||||
to the database. At present, the <option>password</>,
|
to the database. The <option>password</>,
|
||||||
<option>md5</>, and <option>crypt</> authentication methods
|
<option>md5</>, and <option>crypt</> authentication methods
|
||||||
make use of passwords. Database passwords are separate from
|
make use of passwords. Database passwords are separate from
|
||||||
operating system passwords. Specify a password upon user
|
operating system passwords. Specify a password upon user
|
||||||
@ -156,7 +156,7 @@ dropuser <replaceable>name</replaceable>
|
|||||||
ALTER USER myname SET enable_indexscan TO off;
|
ALTER USER myname SET enable_indexscan TO off;
|
||||||
</programlisting>
|
</programlisting>
|
||||||
This will save the setting (but not set it immediately) and in
|
This will save the setting (but not set it immediately) and in
|
||||||
subsequent connections it will appear as though <literal>SET geqo
|
subsequent connections it will appear as though <literal>SET enable_indexscan
|
||||||
TO off;</literal> had been called right before the session started.
|
TO off;</literal> had been called right before the session started.
|
||||||
You can still alter this setting during the session; it will only
|
You can still alter this setting during the session; it will only
|
||||||
be the default. To undo any such setting, use <literal>ALTER USER
|
be the default. To undo any such setting, use <literal>ALTER USER
|
||||||
@ -205,7 +205,7 @@ ALTER GROUP <replaceable>name</replaceable> DROP USER <replaceable>uname1</repla
|
|||||||
<literal>USAGE</>, and <literal>ALL PRIVILEGES</>. For more
|
<literal>USAGE</>, and <literal>ALL PRIVILEGES</>. For more
|
||||||
information on the different types of privileges support by
|
information on the different types of privileges support by
|
||||||
<productname>PostgreSQL</productname>, refer to the
|
<productname>PostgreSQL</productname>, refer to the
|
||||||
<command>GRANT</command> reference manual. The right to modify or
|
<command>GRANT</command> page in the &cite-reference;. The right to modify or
|
||||||
destroy an object is always the privilege of the owner only. To
|
destroy an object is always the privilege of the owner only. To
|
||||||
assign privileges, the <command>GRANT</command> command is
|
assign privileges, the <command>GRANT</command> command is
|
||||||
used. So, if <literal>joe</literal> is an existing user, and
|
used. So, if <literal>joe</literal> is an existing user, and
|
||||||
|
@ -1,5 +1,5 @@
|
|||||||
<!--
|
<!--
|
||||||
$Header: /cvsroot/pgsql/doc/src/sgml/Attic/user.sgml,v 1.33 2002/10/24 17:48:54 petere Exp $
|
$Header: /cvsroot/pgsql/doc/src/sgml/Attic/user.sgml,v 1.34 2002/11/11 20:14:04 petere Exp $
|
||||||
-->
|
-->
|
||||||
|
|
||||||
<book id="user">
|
<book id="user">
|
||||||
@ -29,7 +29,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/Attic/user.sgml,v 1.33 2002/10/24 17:48:54
|
|||||||
database, and how to query it. The middle part lists the
|
database, and how to query it. The middle part lists the
|
||||||
available data types and functions for use in SQL data commands.
|
available data types and functions for use in SQL data commands.
|
||||||
The rest of the book treats several aspects that are important for
|
The rest of the book treats several aspects that are important for
|
||||||
tuning a database for optimial performance.
|
tuning a database for optimal performance.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
|
Reference in New Issue
Block a user