Skip to content

P
Postgres FD Implementation
Commit bf43bed8 authored by Peter Eisentraut's avatar Peter Eisentraut
Browse files
Options

Spell-check and markup police

parent 75f0ba9f
Hide whitespace changes
Inline Side-by-side
Showing with 751 additions and 752 deletions
doc/src/sgml/arch-pg.sgml
View file @ bf43bed8
......@@ -36,7 +36,7 @@
databases on a single host. Such a collection of
databases is called a cluster (of databases). A frontend
application that wishes to access a given database
within a cluster makes calls to an interface library (eg, libpq)
within a cluster makes calls to an interface library (e.g., <application>libpq</>)
that is linked into the application.
The library sends user requests over the network to the
<Application>postmaster</Application>
......@@ -81,7 +81,7 @@ From that point on, the frontend process and the backend
<Para>
You should also be aware that the <Application>postmaster</Application> and
postgres servers run with the user-id of the <ProductName>PostgreSQL</ProductName>
<application>postgres</> servers run with the user ID of the <ProductName>PostgreSQL</ProductName>
<quote>superuser</>.
Note that the <ProductName>PostgreSQL</ProductName> superuser does not
have to be any particular user (e.g., a user named
......
doc/src/sgml/array.sgml
View file @ bf43bed8
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/array.sgml,v 1.18 2001/11/29 21:02:41 tgl Exp $ -->
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/array.sgml,v 1.19 2002/01/20 22:19:55 petere Exp $ -->
<chapter id="arrays">
<title>Arrays</title>
......@@ -244,7 +244,7 @@ SELECT * FROM sal_emp WHERE pay_by_quarter **= 10000;
A limitation of the present array implementation is that individual
elements of an array cannot be SQL NULLs. The entire array can be set
to NULL, but you can't have an array with some elements NULL and some
not. Fixing this is on the TODO list.
not. Fixing this is on the to-do list.
</para>
</note>
......@@ -272,9 +272,9 @@ INSERT ... VALUES ('{"\\\\","\\""}');
</programlisting>
The string-literal processor removes one level of backslashes, so that
what arrives at the array-value parser looks like <literal>{"\\","\""}</>.
In turn, the strings fed to the <type>text</> datatype's input routine
In turn, the strings fed to the <type>text</> data type's input routine
become <literal>\</> and <literal>"</> respectively. (If we were working
with a datatype 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
in the query to get one backslash into the stored array element.)
</para>
......
doc/src/sgml/charset.sgml
View file @ bf43bed8
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/charset.sgml,v 2.20 2002/01/08 05:45:19 momjian Exp $ -->
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/charset.sgml,v 2.21 2002/01/20 22:19:55 petere Exp $ -->
<chapter id="charset">
<title>Localization</>
......@@ -834,7 +834,7 @@ RESET CLIENT_ENCODING;
</para>
<para>
For 7.2, <option>--enable-unicode-conversion</option> is not necessary.
The unicode conversion functionality is automatically enabled
The Unicode conversion functionality is automatically enabled
if <option>--enable-multibyte</option> is specified.
</para>
</sect2>
......@@ -933,7 +933,7 @@ Mar 23, 1999
* Fix problem with MB and locale
Jan 26, 1999
* Add support for Big5 for fronend encoding
* Add support for Big5 for frontend encoding
(you need to create a database with EUC_TW to use Big5)
* Add regression test case for EUC_TW
(contributed by Jonah Kuo <email>jonahkuo@mail.ttn.com.tw</email>)
......@@ -959,7 +959,7 @@ Jun 5, 1998
and the frontend
* new command SET CLIENT_ENCODING etc. added
* add support for LATIN1 character set
* enhance 8 bit cleaness
* enhance 8-bit cleanliness
April 21, 1998 some enhancements/fixes
* character_length(), position(), substring() are now aware of
......
doc/src/sgml/client-auth.sgml
View file @ bf43bed8
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/client-auth.sgml,v 1.31 2001/12/27 21:37:34 tgl Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/client-auth.sgml,v 1.32 2002/01/20 22:19:55 petere Exp $
-->
<chapter id="client-authentication">
......@@ -457,10 +457,10 @@ local all md5 admins
<para>
<literal>trust</> authentication is appropriate and very convenient
for local connections on a single-user workstation. It is usually
<emphasis>not</> appropriate by itself on a multi-user machine.
However, you may be able to use <literal>trust</> even on a multi-user
<emphasis>not</> appropriate by itself on a multiuser machine.
However, you may be able to use <literal>trust</> even on a multiuser
machine, if you restrict access to the postmaster's socket file using
filesystem permissions. To do this, set the parameter
file-system permissions. To do this, set the parameter
<varname>unix_socket_permissions</varname> (and possibly
<varname>unix_socket_group</varname>) in <filename>postgresql.conf</>,
as described in <xref linkend="runtime-config-general">. Or you could
......@@ -469,7 +469,7 @@ local all md5 admins
</para>
<para>
Setting filesystem permissions only helps for Unix-socket connections.
Setting file-system permissions only helps for Unix-socket connections.
Local TCP connections are not restricted by it; therefore, if you want
to use permissions for local security, remove the <literal>host ...
127.0.0.1 ...</> line from <filename>pg_hba.conf</>, or change it to a
......
doc/src/sgml/datatype.sgml
View file @ bf43bed8
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/datatype.sgml,v 1.83 2002/01/07 02:29:11 petere Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/datatype.sgml,v 1.84 2002/01/20 22:19:55 petere Exp $
-->
<chapter id="datatype">
......@@ -978,7 +978,7 @@ SELECT b, char_length(b) FROM test2;
</thead>
<tbody>
<row>
<entry>bytea</entry>
<entry><type>bytea</type></entry>
<entry>4 bytes plus the actual binary string</entry>
<entry>Variable (not specifically limited)
length binary string</entry>
......
doc/src/sgml/datetime.sgml
View file @ bf43bed8
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/datetime.sgml,v 2.25 2002/01/04 17:02:25 thomas Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/datetime.sgml,v 2.26 2002/01/20 22:19:55 petere Exp $
Date/time details
-->
......@@ -211,8 +211,8 @@ Date/time details
The following table of time zones recognized by
<productname>PostgreSQL</productname> is organized by time
zone offset from UTC, rather than alphabetically; this is intended
to faciliate
matching local usage with recognized abreviations for cases where
to facilitate
matching local usage with recognized abbreviations for cases where
these might differ.
<table tocentry="1">
......@@ -1078,8 +1078,8 @@ Date/time details
<note>
<para>
SQL92 states that
<quote>Within the definition of a <sgmltag>datetime literal</sgmltag>,
the <sgmltag>datetime value</sgmltag>s are constrained by the
<quote>Within the definition of a <quote>datetime literal</quote>,
the <quote>datetime value</quote>s are constrained by the
natural rules for dates and times
according to the Gregorian calendar</quote>.
Dates between 1752-09-03 and 1752-09-13, although eliminated in
......
doc/src/sgml/dfunc.sgml
View file @ bf43bed8
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/dfunc.sgml,v 1.19 2002/01/09 00:52:37 petere Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/dfunc.sgml,v 1.20 2002/01/20 22:19:55 petere Exp $
-->
<sect2 id="dfunc">
......@@ -26,7 +26,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/dfunc.sgml,v 1.19 2002/01/09 00:52:37 peter
<para>
<indexterm><primary>PIC</></>
Creating shared libraries is generally analoguous to linking
Creating shared libraries is generally analogous to linking
executables: first the source files are compiled into object files,
then the object files are linked together. The object files need to
be created as <firstterm>position-independent code</firstterm>
......
doc/src/sgml/docguide.sgml
View file @ bf43bed8
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/docguide.sgml,v 1.39 2002/01/08 15:16:16 petere Exp $ -->
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/docguide.sgml,v 1.40 2002/01/20 22:19:55 petere Exp $ -->
<appendix id="docguide">
<title>Documentation</title>
......@@ -515,7 +515,7 @@ CATALOG "docbook-dsssl--1.<replaceable>xx</>/catalog
will need to increase the size of
<application>TeX</application>'s internal data structures.
Details on this can be found in the <application>JadeTeX</application>
installation insructions.
installation instructions.
</para>
<para>
......@@ -738,7 +738,7 @@ gmake man
styles, in particular the default style. If the document
contains <sgmltag>REFENTRY</sgmltag> sections, one must also
replace formatting hints which tie a
<emphasis>preceeding</emphasis> paragraph to the current
<emphasis>preceding</emphasis> paragraph to the current
paragraph, and instead tie the current paragraph to the
following one. A utility, <application>fixrtf</application> is
available in
......@@ -1124,7 +1124,7 @@ Later stylesheets seem to not need this adjustment - thomas 2001-11-29
powerful mode for editing <acronym>SGML</acronym> documents.
When properly configured, it will allow you to use
<application>Emacs</application> to insert tags and check markup
consistancy. You could use it for <acronym>HTML</acronym> as
consistency. You could use it for <acronym>HTML</acronym> as
well. Check the <ulink
url="http://www.lysator.liu.se/projects/about_psgml.html">PSGML
web site</ulink> for downloads, installation instructions, and
......
doc/src/sgml/ecpg.sgml
View file @ bf43bed8
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/ecpg.sgml,v 1.35 2002/01/18 21:17:07 momjian Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/ecpg.sgml,v 1.36 2002/01/20 22:19:55 petere Exp $
-->
<chapter id="ecpg">
......@@ -397,7 +397,7 @@ struct sqlca
<term><computeroutput>-240 (ECPG_UNKNOWN_DESCRIPTOR): Descriptor %s not found in line %d.</computeroutput></term>
<listitem>
<para>
The descriptor specified was not foundstatement you are trying to use has not been prepared.
The descriptor specified was not found. The statement you are trying to use has not been prepared.
</para>
</listitem>
</varlistentry>
......@@ -415,7 +415,7 @@ struct sqlca
<term><computeroutput>-242 (ECPG_UNKNOWN_DESCRIPTOR_ITEM): Descriptor %s not found in line %d.</computeroutput></term>
<listitem>
<para>
The descriptor specified was not foundstatement you are trying to use has not been prepared.
The descriptor specified was not found. The statement you are trying to use has not been prepared.
</para>
</listitem>
</varlistentry>
......
doc/src/sgml/func.sgml
View file @ bf43bed8
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/func.sgml,v 1.90 2002/01/07 02:29:12 petere Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/func.sgml,v 1.91 2002/01/20 22:19:55 petere Exp $
PostgreSQL documentation
-->
......@@ -3925,7 +3925,7 @@ SELECT TIMESTAMP 'now';
just sequences) are special single-row tables created with
<command>CREATE SEQUENCE</>. A sequence object is usually used to
generate unique identifiers for rows of a table. The sequence functions
provide simple, multi-user-safe methods for obtaining successive
provide simple, multiuser-safe methods for obtaining successive
sequence values from sequence objects.
</para>
......@@ -4367,7 +4367,7 @@ SELECT NULLIF(value, '(none)') ...
<row>
<entry><function>pg_get_userbyid</>(<parameter>userid</parameter>)</entry>
<entry><type>name</></entry>
<entry>Get user name given sysid</>
<entry>Get user name given ID</>
</row>
</tbody>
</tgroup>
......@@ -4767,7 +4767,7 @@ OR
<para>
As usual, NULLs in the expressions or subquery rows are combined per
the normal rules of SQL boolean expressions. Two rows are considered
the normal rules of SQL Boolean expressions. Two rows are considered
equal if all their corresponding members are non-null and equal; the rows
are unequal if any corresponding members are non-null and unequal;
otherwise the result of that row comparison is unknown (NULL).
......@@ -4856,7 +4856,7 @@ AND
<para>
As usual, NULLs in the expressions or subquery rows are combined per
the normal rules of SQL boolean expressions. Two rows are considered
the normal rules of SQL Boolean expressions. Two rows are considered
equal if all their corresponding members are non-null and equal; the rows
are unequal if any corresponding members are non-null and unequal;
otherwise the result of that row comparison is unknown (NULL).
......@@ -4875,7 +4875,7 @@ AND
The right-hand side of this form of <token>ANY</> is a parenthesized
subquery, which must return exactly one column. The left-hand expression
is evaluated and compared to each row of the subquery result using the
given <replaceable>operator</replaceable>, which must yield a boolean
given <replaceable>operator</replaceable>, which must yield a Boolean
result.
The result of <token>ANY</> is TRUE if any true result is obtained.
The result is FALSE if no true result is found (including the special
......@@ -4921,7 +4921,7 @@ AND
<para>
As usual, NULLs in the expressions or subquery rows are combined per
the normal rules of SQL boolean expressions. Two rows are considered
the normal rules of SQL Boolean expressions. Two rows are considered
equal if all their corresponding members are non-null and equal; the rows
are unequal if any corresponding members are non-null and unequal;
otherwise the result of that row comparison is unknown (NULL).
......@@ -4939,7 +4939,7 @@ AND
The right-hand side of this form of <token>ALL</> is a parenthesized
subquery, which must return exactly one column. The left-hand expression
is evaluated and compared to each row of the subquery result using the
given <replaceable>operator</replaceable>, which must yield a boolean
given <replaceable>operator</replaceable>, which must yield a Boolean
result.
The result of <token>ALL</> is TRUE if all rows yield TRUE
(including the special case where the subquery returns no rows).
......@@ -4984,7 +4984,7 @@ AND
<para>
As usual, NULLs in the expressions or subquery rows are combined per
the normal rules of SQL boolean expressions. Two rows are considered
the normal rules of SQL Boolean expressions. Two rows are considered
equal if all their corresponding members are non-null and equal; the rows
are unequal if any corresponding members are non-null and unequal;
otherwise the result of that row comparison is unknown (NULL).
......@@ -5014,7 +5014,7 @@ AND
<para>
As usual, NULLs in the expressions or subquery rows are combined per
the normal rules of SQL boolean expressions. Two rows are considered
the normal rules of SQL Boolean expressions. Two rows are considered
equal if all their corresponding members are non-null and equal; the rows
are unequal if any corresponding members are non-null and unequal;
otherwise the result of the row comparison is unknown (NULL).
......
doc/src/sgml/geqo.sgml
View file @ bf43bed8
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/geqo.sgml,v 1.22 2002/01/08 18:03:26 petere Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/geqo.sgml,v 1.23 2002/01/20 22:19:56 petere Exp $
Genetic Optimizer
-->
......@@ -93,7 +93,7 @@ Genetic Optimizer
determined, randomized search. The set of possible solutions for the
optimization problem is considered as a
<firstterm>population</firstterm> of <firstterm>individuals</firstterm>.
The degree of adaption of an individual to its environment is specified
The degree of adaptation of an individual to its environment is specified
by its <firstterm>fitness</firstterm>.
</para>
......@@ -147,7 +147,7 @@ Genetic Optimizer
+=========================================+
| INITIALIZE P(t) |
+=========================================+
| evalute FITNESS of P(t) |
| evaluate FITNESS of P(t) |
+=========================================+
| while not STOPPING CRITERION do |
| +-------------------------------------+
......@@ -157,7 +157,7 @@ Genetic Optimizer
| +-------------------------------------+
| | P(t+1) := SELECTION{P''(t) + P(t)} |
| +-------------------------------------+
| | evalute FITNESS of P''(t) |
| | evaluate FITNESS of P''(t) |
| +-------------------------------------+
| | t := t + 1 |
+===+=====================================+
......@@ -182,7 +182,7 @@ Genetic Optimizer
</literallayout>
is encoded by the integer string '4-1-3-2',
which means, first join relation '4' and '1', then '3', and
then '2', where 1, 2, 3, 4 are relids within the
then '2', where 1, 2, 3, 4 are relation IDs within the
<productname>PostgreSQL</productname> optimizer.
</para>
......
doc/src/sgml/jdbc.sgml
View file @ bf43bed8
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/Attic/jdbc.sgml,v 1.34 2001/11/29 05:35:51 barry Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/Attic/jdbc.sgml,v 1.35 2002/01/20 22:19:56 petere Exp $
-->
<chapter id="jdbc">
......@@ -592,7 +592,7 @@ st.close();
<para>
<application>PostgreSQL</application> provides two distinct ways to
store binary data. Binary data can be stored in a table using
<application>PostgreSQL's</application> binary datatype
<application>PostgreSQL's</application> binary data type
<type>bytea</type>, or by using the <firstterm>Large Object</firstterm>
feature which stores the binary data in a separate table in a special
format, and refers to that table by storing a value of type
......@@ -602,7 +602,7 @@ st.close();
<para>
In order to determine which method is appropriate you
need to understand the limitations of each method. The
<type>bytea</type> datatype is not well suited for storing very
<type>bytea</type> data type is not well suited for storing very
large amounts of binary data. While a column of type
<type>bytea</type> can hold upto 1Gig of binary data, it would
require a huge amount of memory (<acronym>RAM</acronym>) to
......@@ -619,14 +619,14 @@ st.close();
<para>
7.2 is the first release of the <acronym>JDBC</acronym> Driver
that supports the <type>bytea</type> datatype. The introduction of
that supports the <type>bytea</type> data type. The introduction of
this functionality in 7.2 has introduced a change in behavior
as compared to previous releases. In 7.2 the methods
<function>getBytes()</function>, <function>setBytes()</function>,
<function>getBinaryStream()</function>, and
<function>setBinaryStream()</function> operate on
the <type>bytea</type> datatype. In 7.1 these methods operated
on the <type>OID</type> datatype associated with Large Objects.
the <type>bytea</type> data type. In 7.1 these methods operated
on the <type>OID</type> data type associated with Large Objects.
It is possible to revert the driver back to the old 7.1 behavior
by setting the <parameter>compatible</parameter> property on
the <classname>Connection</classname> to a value of
......@@ -634,7 +634,7 @@ st.close();
</para>
<para>
To use the <type>bytea</type> datatype you should simply use
To use the <type>bytea</type> data type you should simply use
the <function>getBytes()</function>, <function>setBytes()</function>,
<function>getBinaryStream()</function>, or
<function>setBinaryStream()</function> methods.
......@@ -663,7 +663,7 @@ st.close();
<acronym>JDBC</acronym> Driver, the <function>getBLOB()</function>
and <function>setBLOB()</function> methods may no longer
interact with Large Objects and will instead work on
<type>bytea</type> datatypes. So it is recommended that you
<type>bytea</type> data types. So it is recommended that you
use the <classname>LargeObject</classname> <acronym>API</acronym>
if you intend to use Large Objects.
</para></note>
......@@ -728,7 +728,7 @@ ps.close();
</para>
<para>
Alternativly you could be storing a very large file and want to use
Alternatively you could be storing a very large file and want to use
the <classname>LargeObject</classname> <acronym>API</acronym> to
store the file:
<programlisting>
......
doc/src/sgml/libpgtcl.sgml
View file @ bf43bed8
......@@ -1194,8 +1194,8 @@ The oid of the large object created.
<TITLE>Usage
</TITLE>
<PARA>
mode can be any OR'ing together of INV_READ and INV_WRITE.
The OR delimiter character is <literal>|</literal>.
mode can be any or'ing together of <literal>INV_READ</> and <literal>INV_WRITE</>.
The <quote>or</quote> operator is <literal>|</literal>.
<ProgramListing>
[pg_lo_creat $conn "INV_READ|INV_WRITE"]
</ProgramListing>
......
doc/src/sgml/lobj.sgml
View file @ bf43bed8
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/lobj.sgml,v 1.25 2002/01/07 02:29:12 petere Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/lobj.sgml,v 1.26 2002/01/20 22:19:56 petere Exp $
-->
<chapter id="largeObjects">
......@@ -175,7 +175,7 @@ Oid lo_import(PGconn *<replaceable class="parameter">conn</replaceable>, const c
<synopsis>
int lo_export(PGconn *<replaceable class="parameter">conn</replaceable>, Oid <replaceable class="parameter">lobjId</replaceable>, const char *<replaceable class="parameter">filename</replaceable>)
</synopsis>
The <parameter>lobjId</parameter> argument specifies the Oid of the large
The <parameter>lobjId</parameter> argument specifies the OID of the large
object to export and the <parameter>filename</parameter> argument specifies
the operating system name name of the file.
</para>
......@@ -189,7 +189,7 @@ int lo_export(PGconn *<replaceable class="parameter">conn</replaceable>, Oid <re
<synopsis>
int lo_open(PGconn *conn, Oid lobjId, int mode)
</synopsis>
The <parameter>lobjId</parameter> argument specifies the Oid of the large
The <parameter>lobjId</parameter> argument specifies the OID of the large
object to open. The <parameter>mode</parameter> bits control whether the
object is opened for reading (<symbol>INV_READ</>), writing (<symbol>INV_WRITE</symbol>), or
both.
......@@ -269,7 +269,7 @@ int lo_close(PGconn *conn, int fd)
<synopsis>
Oid lo_unlink(PGconn *<replaceable class="parameter">conn</replaceable>, Oid lobjId)
</synopsis>
The <parameter>lobjId</parameter> argument specifies the Oid of the large
The <parameter>lobjId</parameter> argument specifies the OID of the large
object to remove.
</para>
</sect2>
......
doc/src/sgml/maintenance.sgml
View file @ bf43bed8
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/maintenance.sgml,v 1.10 2001/11/28 20:49:10 petere Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/maintenance.sgml,v 1.11 2002/01/20 22:19:56 petere Exp $
-->
<chapter id="maintenance">
......@@ -377,16 +377,16 @@ VACUUM
It's a good idea to save the database server's log output somewhere,
rather than just routing it to <filename>/dev/null</>. The log output
is invaluable when it comes time to diagnose problems. However, the
log output tends to be voluminuous (especially at higher debug levels)
log output tends to be voluminous (especially at higher debug levels)
and you won't want to save it indefinitely. You need to <quote>rotate</>
the log files so that new log files are started and old ones thrown
away every so often.
</para>
<para>
If you simply direct the postmaster's stderr into a file, the only way
If you simply direct the postmaster's <systemitem>stderr</> into a file, the only way
to truncate the log file is to stop and restart the postmaster. This
may be okay for development setups but you won't want to run a production
may be OK for development setups but you won't want to run a production
server that way.
</para>
......@@ -406,9 +406,9 @@ VACUUM
On many systems, however, syslog is not very reliable, particularly
with large log messages; it may truncate or drop messages just when
you need them the most. You may find it more useful to pipe the
<application>postmaster</>'s stderr to some type of log rotation script.
<application>postmaster</>'s <systemitem>stderr</> to some type of log rotation script.
If you start the postmaster with <application>pg_ctl</>, then the
postmaster's stderr is already redirected to stdout, so you just need a
postmaster's <systemitem>stderr</> is already redirected to <systemitem>stdout</>, so you just need a
pipe command:
<screen>
......
doc/src/sgml/manage.sgml
View file @ bf43bed8
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/Attic/manage.sgml,v 1.20 2001/11/21 05:53:41 thomas Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/Attic/manage.sgml,v 1.21 2002/01/20 22:19:56 petere Exp $
-->
<Chapter Id="manage">
......@@ -94,7 +94,7 @@ ERROR: CREATE DATABASE: Permission denied.
<listitem>
<para>
Running the <productname>PostgreSQL</productname> interactive
terminal program, called <quote>psql</quote>, which allows you
terminal program, called <application>psql</application>, which allows you
to interactively enter, edit, and execute
<acronym>SQL</acronym> commands.
</para>
......@@ -145,7 +145,7 @@ mydb=>
<Para>
This prompt indicates that <command>psql</command> is listening
to you and that you can type <Acronym>SQL</Acronym> queries into a
workspace maintained by the terminal monitor.
work space maintained by the terminal monitor.
The <Application>psql</Application> program itself responds to special
commands that begin
with the backslash character, <literal>\</literal>. For example, you
......@@ -156,7 +156,7 @@ mydb=> \h
</ProgramListing>
Once you have finished entering your queries into the
workspace, you can pass the contents of the workspace
work space, you can pass the contents of the work space
to the <ProductName>PostgreSQL</ProductName> server by typing:
<ProgramListing>
mydb=> \g
......
doc/src/sgml/mvcc.sgml
View file @ bf43bed8
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/mvcc.sgml,v 2.21 2001/11/28 20:49:10 petere Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/mvcc.sgml,v 2.22 2002/01/20 22:19:56 petere Exp $
-->
<chapter id="mvcc">
<title>Multi-Version Concurrency Control</title>
<title>Multiversion Concurrency Control</title>
<indexterm>
<primary>concurrency</primary>
......@@ -11,10 +11,10 @@ $Header: /cvsroot/pgsql/doc/src/sgml/mvcc.sgml,v 2.21 2001/11/28 20:49:10 petere
<abstract>
<para>
Multi-Version Concurrency Control
Multiversion Concurrency Control
(MVCC)
is an advanced technique for improving database performance in a
multi-user environment.
multiuser environment.
Vadim Mikheev (<email>vadim@krs.ru</email>) provided
the implementation for <productname>PostgreSQL</productname>.
</para>
......
doc/src/sgml/nls.sgml
View file @ bf43bed8
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/nls.sgml,v 1.2 2001/11/21 05:53:41 thomas Exp $ -->
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/nls.sgml,v 1.3 2002/01/20 22:19:56 petere Exp $ -->
<chapter id="nls">
<docinfo>
......@@ -333,7 +333,7 @@ textdomain("<replaceable>progname</replaceable>");
<step>
<para>
Whereever a message that is a candidate for translation is found,
Wherever a message that is a candidate for translation is found,
a call to <function>gettext()</function> needs to be inserted. E.g.,
<programlisting>
fprintf(stderr, "panic level %d\n", lvl);
......@@ -473,7 +473,7 @@ printf("number of copied files: %d", n);
<para>
If you want to communicate something to the translator, such as
about how a message is intended to line up with other output,
precede the occurance of the string with a comment that starts
precede the occurrance of the string with a comment that starts
with <literal>translator</literal>, e.g.,
<programlisting>
/* translator: This message is not what it seems to be. */
......
doc/src/sgml/perform.sgml
View file @ bf43bed8
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/perform.sgml,v 1.15 2001/11/28 20:49:10 petere Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/perform.sgml,v 1.16 2002/01/20 22:19:56 petere Exp $
-->
<chapter id="performance-tips">
......@@ -403,7 +403,7 @@ regression=#
</para>
<table>
<title>pg_stats Columns</title>
<title><structname>pg_stats</structname> Columns</title>
<tgroup cols=3>
<thead>
......@@ -416,31 +416,31 @@ regression=#
<tbody>
<row>
<entry>tablename</entry>
<entry><literal>tablename</literal></entry>
<entry><type>name</type></entry>
<entry>Name of table containing column</entry>
</row>
<row>
<entry>attname</entry>
<entry><literal>attname</literal></entry>
<entry><type>name</type></entry>
<entry>Column described by this row</entry>
</row>
<row>
<entry>null_frac</entry>
<entry><literal>null_frac</literal></entry>
<entry><type>real</type></entry>
<entry>Fraction of column's entries that are NULL</entry>
</row>
<row>
<entry>avg_width</entry>
<entry><literal>avg_width</literal></entry>
<entry><type>integer</type></entry>
<entry>Average width in bytes of column's entries</entry>
</row>
<row>
<entry>n_distinct</entry>
<entry><literal>n_distinct</literal></entry>
<entry><type>real</type></entry>
<entry>If greater than zero, the estimated number of distinct values
in the column. If less than zero, the negative of the number of
......@@ -454,14 +454,14 @@ regression=#
</row>
<row>
<entry>most_common_vals</entry>
<entry><literal>most_common_vals</literal></entry>
<entry><type>text[]</type></entry>
<entry>A list of the most common values in the column. (Omitted if
no values seem to be more common than any others.)</entry>
</row>
<row>
<entry>most_common_freqs</entry>
<entry><literal>most_common_freqs</literal></entry>
<entry><type>real[]</type></entry>
<entry>A list of the frequencies of the most common values,
ie, number of occurrences of each divided by total number of rows.
......@@ -474,7 +474,7 @@ regression=#
<entry>A list of values that divide the column's values into
groups of approximately equal population. The
<structfield>most_common_vals</>, if present, are omitted from the
histogram calculation. (Omitted if column datatype does not have a
histogram calculation. (Omitted if column data type does not have a
<literal>&lt;</> operator, or if the <structfield>most_common_vals</>
list accounts for the entire population.)
</entry>
......@@ -485,9 +485,9 @@ regression=#
<entry><type>real</type></entry>
<entry>Statistical correlation between physical row ordering and
logical ordering of the column values. This ranges from -1 to +1.
When the value is near -1 or +1, an indexscan on the column will
When the value is near -1 or +1, an index scan on the column will
be estimated to be cheaper than when it is near zero, due to reduction
of random access to the disk. (Omitted if column datatype does
of random access to the disk. (Omitted if column data type does
not have a <literal>&lt;</> operator.)
</entry>
</row>
......
doc/src/sgml/problems.sgml
View file @ bf43bed8
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/problems.sgml,v 2.12 2002/01/07 02:29:13 petere Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/problems.sgml,v 2.13 2002/01/20 22:19:56 petere Exp $
-->
<sect1 id="bug-reporting">
......@@ -265,7 +265,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/problems.sgml,v 2.12 2002/01/07 02:29:13 pe
backend server process is quite different from crash of the parent
<quote>postmaster</> process; please don't say <quote>the postmaster
crashed</> when you mean a single backend went down, nor vice versa.
Also, client programs such as the interactive frontend <quote>psql</quote>
Also, client programs such as the interactive frontend <quote><application>psql</application></quote>
are completely separate from the backend. Please try to be specific
about whether the problem is on the client or server side.
</para>
......@@ -305,7 +305,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/problems.sgml,v 2.12 2002/01/07 02:29:13 pe
development of <productname>PostgreSQL</productname> and it would be nice
if we could keep the bug reports separate. We might choose to take up a
discussion
about your bug report on pgsql-hackers, if the problem needs more review.
about your bug report on <literal>pgsql-hackers</literal>, if the problem needs more review.
</para>
<para>
......
doc/src/sgml/query.sgml
View file @ bf43bed8
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/query.sgml,v 1.24 2002/01/07 02:29:13 petere Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/query.sgml,v 1.25 2002/01/20 22:19:56 petere Exp $
-->
<chapter id="tutorial-sql">
......@@ -21,7 +21,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/query.sgml,v 1.24 2002/01/07 02:29:13 peter
<para>
In the examples that follow, we assume that you have created a
database named <quote>mydb</quote>, as described in the previous
database named <literal>mydb</literal>, as described in the previous
chapter, and have started <application>psql</application>.
</para>
......@@ -693,7 +693,7 @@ SELECT city, max(temp_lo)
<para>
It is important to understand the interaction between aggregates and
SQL's <literal>WHERE</literal> and <literal>HAVING</literal> clauses.
<acronym>SQL</acronym>'s <literal>WHERE</literal> and <literal>HAVING</literal> clauses.
The fundamental difference between <literal>WHERE</literal> and
<literal>HAVING</literal> is this: <literal>WHERE</literal> selects
input rows before groups and aggregates are computed (thus, it controls
......
doc/src/sgml/recovery.sgml
View file @ bf43bed8
......@@ -13,7 +13,7 @@
Database recovery is necessary in the event of hardware or software
failure. There are several categories of failures; some of these
require relatively minor adjustments to the database, while others
may depend on the existance of previously prepared database dumps
may depend on the existence of previously prepared database dumps
and other recovery data sets. It should be emphasized that if your
data is important and/or difficult to regenerate, then you should
have considered and prepared for various failure scenarios.
......@@ -44,7 +44,7 @@
that the database be recovered from a previously prepared database
dump. This dump must be prepared using
<application>pg_dumpall</application>, and updates to the database
occuring after the database installation was dumped will be lost.
occurring after the database installation was dumped will be lost.
</para>
</sect1>
......
doc/src/sgml/ref/alter_table.sgml
View file @ bf43bed8
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/ref/alter_table.sgml,v 1.34 2001/12/08 03:24:33 thomas Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/ref/alter_table.sgml,v 1.35 2002/01/20 22:19:56 petere Exp $
PostgreSQL documentation
-->
......@@ -246,7 +246,7 @@ DROP TABLE temp;
Usage
</title>
<para>
To add a column of type VARCHAR to a table:
To add a column of type <type>varchar</type> to a table:
<programlisting>
ALTER TABLE distributors ADD COLUMN address VARCHAR(30);
</programlisting>
......@@ -288,7 +288,7 @@ ALTER TABLE distributors ADD CONSTRAINT distfk FOREIGN KEY (address) REFERENCES
</para>
<para>
To add a (multi-column) unique constraint to a table:
To add a (multicolumn) unique constraint to a table:
<programlisting>
ALTER TABLE distributors ADD CONSTRAINT dist_id_zipcode_key UNIQUE (dist_id, zipcode);
</programlisting>
......
doc/src/sgml/ref/analyze.sgml
View file @ bf43bed8
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/ref/analyze.sgml,v 1.5 2001/12/08 03:24:34 thomas Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/ref/analyze.sgml,v 1.6 2002/01/20 22:19:56 petere Exp $
PostgreSQL documentation
-->
......@@ -152,7 +152,7 @@ ANALYZE [ VERBOSE ] [ <replaceable class="PARAMETER">table</replaceable> [ (<rep
distribution in each column. One or both of these may be omitted if
<command>ANALYZE</command> deems them uninteresting (for example, in
a unique-key column, there are no common values) or if the column
datatype does not support the appropriate operators. There is more
data type does not support the appropriate operators. There is more
information about the statistics in the <citetitle>User's
Guide</citetitle>.
</para>
......
doc/src/sgml/ref/close.sgml
View file @ bf43bed8
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/ref/close.sgml,v 1.9 2001/12/08 03:24:34 thomas Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/ref/close.sgml,v 1.10 2002/01/20 22:19:56 petere Exp $
PostgreSQL documentation
-->
......@@ -125,7 +125,7 @@ NOTICE PerformPortalClose: portal "<replaceable class="PARAMETER">cursor</replac
Usage
</title>
<para>
Close the cursor liahona:
Close the cursor <literal>liahona</literal>:
</para>
<programlisting>
CLOSE liahona;
......
doc/src/sgml/ref/copy.sgml
View file @ bf43bed8
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/ref/copy.sgml,v 1.26 2001/12/08 03:24:34 thomas Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/ref/copy.sgml,v 1.27 2002/01/20 22:19:56 petere Exp $
PostgreSQL documentation
-->
......@@ -74,7 +74,7 @@ COPY [ BINARY ] <replaceable class="parameter">table</replaceable> [ WITH OIDS ]
<term><replaceable class="parameter">filename</replaceable></term>
<listitem>
<para>
The absolute Unix pathname of the input or output file.
The absolute Unix file name of the input or output file.
</para>
</listitem>
</varlistentry>
......@@ -181,7 +181,7 @@ ERROR: <replaceable>reason</replaceable>
</para>
<para>
<command>COPY</command> with a filename instructs
<command>COPY</command> with a file name instructs
the <productname>PostgreSQL</productname> backend
to directly read from or write to a file.
The file must be accessible to the backend and the name must be specified
......@@ -262,8 +262,8 @@ ERROR: <replaceable>reason</replaceable>
directly by the backend, not by the client application. Therefore,
they must reside on or be accessible to the database server machine,
not the client. They must be accessible to and readable or writable
by the <application>PostgreSQL</application> user (the userid the
backend runs as), not the client.
by the <application>PostgreSQL</application> user (the user ID the
server runs as), not the client.
<command>COPY</command> naming a file is only allowed to database
superusers, since it allows writing on any file that the backend has
privileges to write on.
......@@ -483,7 +483,7 @@ The typlen field is interpreted thus:
<term>&gt; 0</term>
<listitem>
<para>
Field is a fixed-length datatype. Exactly N
Field is a fixed-length data type. Exactly N
bytes of data follow the typlen word.
</para>
</listitem>
......@@ -493,7 +493,7 @@ The typlen field is interpreted thus:
<term>-1</term>
<listitem>
<para>
Field is a varlena datatype. The next four
Field is a varlena data type. The next four
bytes are the varlena header, which contains
the total value length including itself.
</para>
......@@ -519,7 +519,7 @@ but very useful check that the data is as expected.
<para>
There is no alignment padding or any other extra data between fields.
Note also that the format does not distinguish whether a datatype is
Note also that the format does not distinguish whether a data type is
pass-by-reference or pass-by-value. Both of these provisions are
deliberate: they might help improve portability of the files (although
of course endianness and floating-point-format issues can still keep
......
doc/src/sgml/ref/create_constraint.sgml
View file @ bf43bed8
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_constraint.sgml,v 1.4 2001/12/08 03:24:34 thomas Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_constraint.sgml,v 1.5 2002/01/20 22:19:56 petere Exp $
PostgreSQL documentation
-->
......@@ -67,7 +67,7 @@ CREATE CONSTRAINT TRIGGER <replaceable class="parameter">name</replaceable>
<term><replaceable class="PARAMETER">constraint</replaceable></term>
<listitem>
<para>
Actual onstraint specification.
Actual constraint specification.
</para>
</listitem>
</varlistentry>
......
doc/src/sgml/ref/create_database.sgml
View file @ bf43bed8
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_database.sgml,v 1.22 2001/12/08 03:24:34 thomas Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_database.sgml,v 1.23 2002/01/20 22:19:56 petere Exp $
PostgreSQL documentation
-->
......@@ -51,7 +51,7 @@ CREATE DATABASE <replaceable class="PARAMETER">name</replaceable>
<term><replaceable class="parameter">dbpath</replaceable></term>
<listitem>
<para>
An alternate filesystem location in which to store the new database,
An alternate file-system location in which to store the new database,
specified as a string literal;
or <literal>DEFAULT</literal> to use the default location.
</para>
......
doc/src/sgml/ref/create_group.sgml
View file @ bf43bed8
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_group.sgml,v 1.6 2001/12/08 03:24:34 thomas Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_group.sgml,v 1.7 2002/01/20 22:19:56 petere Exp $
PostgreSQL documentation
-->
......@@ -110,7 +110,7 @@ where <replaceable class="PARAMETER">option</replaceable> can be:
</title>
<para>
CREATE GROUP will create a new group in the database installation.
Refer to the adminstrator's guide for information about using groups
Refer to the <citetitle>Administrator's Guide</citetitle> for information about using groups
for authentication.
You must be a database superuser to use this command.
</para>
......
doc/src/sgml/ref/create_index.sgml
View file @ bf43bed8
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_index.sgml,v 1.25 2001/12/08 03:24:34 thomas Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_index.sgml,v 1.26 2002/01/20 22:19:56 petere Exp $
PostgreSQL documentation
-->
......@@ -77,7 +77,7 @@ CREATE [ UNIQUE ] INDEX <replaceable class="parameter">index_name</replaceable>
<listitem>
<para>
The name of the access method to be used for
the index. The default access method is BTREE.
the index. The default access method is <literal>BTREE</literal>.
<application>PostgreSQL</application> provides four access methods for indexes:
<variablelist>
......@@ -86,7 +86,7 @@ CREATE [ UNIQUE ] INDEX <replaceable class="parameter">index_name</replaceable>
<listitem>
<para>
an implementation of Lehman-Yao
high-concurrency btrees.
high-concurrency B-trees.
</para>
</listitem>
</varlistentry>
......@@ -94,7 +94,7 @@ CREATE [ UNIQUE ] INDEX <replaceable class="parameter">index_name</replaceable>
<varlistentry>
<term>RTREE</term>
<listitem>
<para>implements standard rtrees using Guttman's
<para>implements standard R-trees using Guttman's
quadratic split algorithm.
</para>
</listitem>
......@@ -221,7 +221,7 @@ ERROR: Cannot create index: 'index_name' already exists.
In the first syntax shown above, the key field(s) for the
index are specified as column names.
Multiple fields can be specified if the index access method supports
multi-column indexes.
multicolumn indexes.
</para>
<para>
......@@ -236,10 +236,10 @@ ERROR: Cannot create index: 'index_name' already exists.
</para>
<para>
<application>PostgreSQL</application> provides btree, rtree, hash, and GiST access methods for
indexes. The btree access method is an implementation of
Lehman-Yao high-concurrency btrees. The rtree access method
implements standard rtrees using Guttman's quadratic split algorithm.
<application>PostgreSQL</application> provides B-tree, R-tree, hash, and GiST access methods for
indexes. The B-tree access method is an implementation of
Lehman-Yao high-concurrency B-trees. The R-tree access method
implements standard R-trees using Guttman's quadratic split algorithm.
The hash access method is an implementation of Litwin's linear
hashing. We mention the algorithms used solely to indicate that all
of these access methods are fully dynamic and do not have to be
......@@ -293,7 +293,7 @@ ERROR: Cannot create index: 'index_name' already exists.
<para>
The <productname>PostgreSQL</productname>
query optimizer will consider using a btree index whenever
query optimizer will consider using a B-tree index whenever
an indexed attribute is involved in a comparison using one of:
<simplelist type="inline">
......@@ -307,7 +307,7 @@ ERROR: Cannot create index: 'index_name' already exists.
<para>
The <productname>PostgreSQL</productname>
query optimizer will consider using an rtree index whenever
query optimizer will consider using an R-tree index whenever
an indexed attribute is involved in a comparison using one of:
<simplelist type="inline">
......@@ -329,17 +329,17 @@ ERROR: Cannot create index: 'index_name' already exists.
</para>
<para>
Currently, only the btree and gist access methods support multi-column
Currently, only the B-tree and gist access methods support multi-column
indexes. Up to 16 keys may be specified by default (this limit
can be altered when building
<application>PostgreSQL</application>). Only btree currently supports
<application>PostgreSQL</application>). Only B-tree currently supports
unique indexes.
</para>
<para>
An <firstterm>operator class</firstterm> can be specified for each
column of an index. The operator class identifies the operators to
be used by the index for that column. For example, a btree index on
be used by the index for that column. For example, a B-tree index on
four-byte integers would use the <literal>int4_ops</literal> class;
this operator class includes comparison functions for four-byte
integers. In practice the default operator class for the field's
......@@ -355,7 +355,7 @@ ERROR: Cannot create index: 'index_name' already exists.
<listitem>
<para>
The operator classes <literal>box_ops</literal> and
<literal>bigbox_ops</literal> both support rtree indexes on the
<literal>bigbox_ops</literal> both support R-tree indexes on the
<literal>box</literal> data type.
The difference between them is that <literal>bigbox_ops</literal>
scales box coordinates down, to avoid floating-point exceptions from
......@@ -389,7 +389,7 @@ SELECT am.amname AS acc_method,
<title>
Usage
</title>
<para>To create a btree index on the field <literal>title</literal>
<para>To create a B-tree index on the field <literal>title</literal>
in the table <literal>films</literal>:
</para>
<programlisting>
......@@ -402,7 +402,7 @@ CREATE UNIQUE INDEX title_idx
Is this example correct?
</comment>
<para>
To create a rtree index on a point attribute so that we
To create a R-tree index on a point attribute so that we
can efficiently use box operators on the result of the
conversion function:
</para>
......
doc/src/sgml/ref/create_operator.sgml
View file @ bf43bed8
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_operator.sgml,v 1.23 2002/01/07 02:29:15 petere Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_operator.sgml,v 1.24 2002/01/20 22:19:56 petere Exp $
PostgreSQL documentation
-->
......@@ -175,7 +175,7 @@ CREATE
</para>
<para>
The operator <replaceable class="parameter">name</replaceable>
is a sequence of up to NAMEDATALEN-1 (31 by default) characters
is a sequence of up to <symbol>NAMEDATALEN</>-1 (31 by default) characters
from the following list:
<literallayout>
+ - * / &lt; &gt; = ~ ! @ # % ^ &amp; | ` ? $
......@@ -186,7 +186,7 @@ CREATE
<listitem>
<para>
<literal>$</literal> cannot be defined as a single-character operator,
although it can be part of a multi-character operator name.
although it can be part of a multicharacter operator name.
</para>
</listitem>
<listitem>
......@@ -197,7 +197,7 @@ CREATE
</listitem>
<listitem>
<para>
A multi-character operator name cannot end in <literal>+</literal> or
A multicharacter operator name cannot end in <literal>+</literal> or
<literal>-</literal>,
unless the name also contains at least one of these characters:
<literallayout>
......@@ -299,7 +299,7 @@ MYBOXES.description !== box '((0,0), (1,1))'
query optimizer in performing joins.
<productname>PostgreSQL</productname> can always
evaluate a join (i.e., processing a clause with two tuple
variables separated by an operator that returns a boolean)
variables separated by an operator that returns a <type>boolean</type>)
by iterative substitution [WONG76].
In addition, <productname>PostgreSQL</productname>
can use a hash-join algorithm along
......
doc/src/sgml/ref/create_sequence.sgml
View file @ bf43bed8
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_sequence.sgml,v 1.23 2001/12/08 03:24:35 thomas Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_sequence.sgml,v 1.24 2002/01/20 22:19:56 petere Exp $
PostgreSQL documentation
-->
......@@ -265,9 +265,9 @@ SELECT * FROM <replaceable>seqname</replaceable>;
will be lost when that session ends. Furthermore, although multiple backends are guaranteed to
allocate distinct sequence values, the values may be generated out of
sequence when all the backends are considered. (For example, with a <replaceable class="parameter">cache</replaceable>
setting of 10, backend A might reserve values 1..10 and return nextval=1,
setting of 10, backend A might reserve values 1..10 and return <function>nextval</function>=1,
then
backend B might reserve values 11..20 and return nextval=11 before backend
backend B might reserve values 11..20 and return <function>nextval</function>=11 before backend
A has generated nextval=2.) Thus, with a <replaceable class="parameter">cache</replaceable> setting of one it is safe
to assume that <function>nextval</> values are generated sequentially; with a <replaceable class="parameter">cache</replaceable>
setting greater than one you should only assume that the <function>nextval</> values
......
doc/src/sgml/ref/create_table.sgml
View file @ bf43bed8
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_table.sgml,v 1.51 2002/01/03 06:26:22 momjian Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_table.sgml,v 1.52 2002/01/20 22:19:56 petere Exp $
PostgreSQL documentation
-->
......@@ -367,7 +367,7 @@ and <replaceable class="PARAMETER">table_constraint</replaceable> is:
match type. There are three match types: <literal>MATCH
FULL</>, <literal>MATCH PARTIAL</>, and a default match type if
none is specified. <literal>MATCH FULL</> will not allow one
column of a multi-column foreign key to be NULL unless all
column of a multicolumn foreign key to be NULL unless all
foreign key columns are NULL. The default match type allows some
foreign key columns to be NULL while other parts of the foreign
key are not NULL. <literal>MATCH PARTIAL</> is not yet
......@@ -583,7 +583,7 @@ and <replaceable class="PARAMETER">table_constraint</replaceable> is:
<para>
Unique constraints and primary keys are not inherited in the
current implementation. This makes the combination of
inheritance and unique constraints rather disfunctional.
inheritance and unique constraints rather dysfunctional.
</para>
</listitem>
</itemizedlist>
......@@ -800,7 +800,7 @@ CREATE { GLOBAL | LOCAL } TEMPORARY TABLE <replaceable class="parameter">table</
The <literal>NULL</> <quote>constraint</quote> (actually a
non-constraint) is a <productname>PostgreSQL</productname>
extension to SQL92 that is included for compatibility with some
other RDBMSes (and for symmetry with the <literal>NOT
other RDBMS (and for symmetry with the <literal>NOT
NULL</literal> constraint). Since it is the default for any
column, its presence is simply noise.
</para>
......
doc/src/sgml/ref/create_trigger.sgml
View file @ bf43bed8
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_trigger.sgml,v 1.21 2001/12/08 03:24:35 thomas Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_trigger.sgml,v 1.22 2002/01/20 22:19:56 petere Exp $
PostgreSQL documentation
-->
......@@ -232,7 +232,7 @@ CREATE TABLE distributors (
<listitem>
<para>
SQL99 allows you to define aliases for the <quote>old</quote>
and <quote>new</quote> rows or tables for use in the definiton
and <quote>new</quote> rows or tables for use in the definition
of the triggered action (e.g., <literal>CREATE TRIGGER ... ON
tablename REFERENCING OLD ROW AS somename NEW ROW AS
othername ...</literal>). Since
......
doc/src/sgml/ref/create_type.sgml
View file @ bf43bed8
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_type.sgml,v 1.25 2001/12/08 03:24:35 thomas Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_type.sgml,v 1.26 2002/01/20 22:19:56 petere Exp $
PostgreSQL documentation
-->
......@@ -238,7 +238,7 @@ CREATE
declared as taking one argument of type <type>opaque</type>,
or as taking two arguments of types
<type>opaque</type>, <type>OID</type>.
(The first argument is actually of the datatype itself, but since the
(The first argument is actually of the data type itself, but since the
output function must be declared first, it's easier to declare it as
accepting type <type>opaque</type>. The second argument is again
the array element type for array types.)
......@@ -282,7 +282,7 @@ CREATE
<para>
A default value may be specified, in case a user wants columns of the
datatype to default to something other than NULL.
data type to default to something other than NULL.
Specify the default with the <option>DEFAULT</option> keyword.
(Such a default may be overridden by an explicit <option>DEFAULT</option>
clause attached to a particular column.)
......@@ -311,7 +311,7 @@ CREATE
<para>
The <replaceable class="parameter">alignment</replaceable> keyword
specifies the storage alignment required for the datatype. The
specifies the storage alignment required for the data type. The
allowed values equate to alignment on 1, 2, 4, or 8 byte boundaries.
Note that variable-length types must have an alignment of at least
4, since they necessarily contain an <type>int4</> as their first component.
......@@ -339,7 +339,7 @@ CREATE
<title>Array Types</title>
<para>
Whenever a user-defined datatype is created,
Whenever a user-defined data type is created,
<productname>PostgreSQL</productname> automatically creates an
associated array type, whose name consists of the base type's
name prepended with an underscore. The parser understands this
......@@ -358,7 +358,7 @@ CREATE
identical things, and you want to allow the N things to be accessed
directly by subscripting, in addition to whatever operations you plan
to provide for the type as a whole. For example, type <type>name</>
allows its constitutent <type>char</>s to be accessed this way.
allows its constituent <type>char</>s to be accessed this way.
A 2-D <type>point</> type could allow its two component floats to be
accessed like <literal>point[0]</> and <literal>point[1]</>.
Note that
......
doc/src/sgml/ref/createdb.sgml
View file @ bf43bed8
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/ref/createdb.sgml,v 1.23 2001/12/08 03:24:35 thomas Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/ref/createdb.sgml,v 1.24 2002/01/20 22:19:56 petere Exp $
PostgreSQL documentation
-->
......@@ -238,7 +238,7 @@ PostgreSQL documentation
<informalexample>
<para>
To create the database <literal>demo</literal> using the
server on host eden, port 5000, using the
server on host <literal>eden</>, port 5000, using the
<literal>LATIN1</literal> encoding scheme with a look at the
underlying query:
<screen>
......
doc/src/sgml/ref/createuser.sgml
View file @ bf43bed8
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/ref/createuser.sgml,v 1.22 2001/12/08 03:24:35 thomas Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/ref/createuser.sgml,v 1.23 2002/01/20 22:19:56 petere Exp $
PostgreSQL documentation
-->
......@@ -255,7 +255,7 @@ PostgreSQL documentation
<informalexample>
<para>
To create the same user <literal>joe</literal> using the
server on host eden, port 5000, avoiding the prompts and
server on host <literal>eden</>, port 5000, avoiding the prompts and
taking a look at the underlying query:
<screen>
<prompt>$ </prompt><userinput>createuser -p 5000 -h eden -D -A -e joe</userinput>
......
doc/src/sgml/ref/drop_aggregate.sgml
View file @ bf43bed8
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/ref/drop_aggregate.sgml,v 1.14 2001/12/08 03:24:35 thomas Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/ref/drop_aggregate.sgml,v 1.15 2002/01/20 22:19:56 petere Exp $
PostgreSQL documentation
-->
......@@ -47,7 +47,7 @@ DROP AGGREGATE <replaceable class="PARAMETER">name</replaceable> ( <replaceable
<term><replaceable class="parameter">type</replaceable></term>
<listitem>
<para>
The input datatype of an existing aggregate function,
The input data type of an existing aggregate function,
or <literal>*</literal> if the function accepts any input type.
(Refer to the <citetitle>PostgreSQL User's Guide</citetitle> for
further information about data types.)
......
doc/src/sgml/ref/drop_operator.sgml
View file @ bf43bed8
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/ref/drop_operator.sgml,v 1.12 2001/12/08 03:24:36 thomas Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/ref/drop_operator.sgml,v 1.13 2002/01/20 22:19:56 petere Exp $
PostgreSQL documentation
-->
......@@ -176,7 +176,7 @@ DROP OPERATOR ^ (int4, int4);
</programlisting>
</para>
<para>
Remove left unary negation operator (<literal>! b</literal>) for booleans:
Remove left unary negation operator (<literal>! b</literal>) for <type>boolean</type>:
<programlisting>
DROP OPERATOR ! (none, bool);
</programlisting>
......
doc/src/sgml/ref/drop_type.sgml
View file @ bf43bed8
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/ref/drop_type.sgml,v 1.13 2001/12/08 03:24:36 thomas Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/ref/drop_type.sgml,v 1.14 2002/01/20 22:19:56 petere Exp $
PostgreSQL documentation
-->
......@@ -105,7 +105,7 @@ ERROR: RemoveType: type '<replaceable class="parameter">typename</replaceable>'
<para>
It is the user's responsibility to remove any operators,
functions, aggregates, access methods, subtypes, and tables that
use a deleted type. However, the associated array datatype
use a deleted type. However, the associated array data type
(which was automatically created by <command>CREATE TYPE</command>)
will be removed automatically.
</para>
......
doc/src/sgml/ref/drop_user.sgml
View file @ bf43bed8
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/ref/drop_user.sgml,v 1.13 2001/12/08 03:24:36 thomas Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/ref/drop_user.sgml,v 1.14 2002/01/20 22:19:56 petere Exp $
PostgreSQL documentation
-->
......@@ -72,7 +72,7 @@ ERROR: DROP USER: user "<replaceable class="parameter">name</replaceable>" does
</computeroutput></term>
<listitem>
<para>
This message occurs if the username is not found.
This message occurs if the user name is not found.
</para>
</listitem>
</varlistentry>
......
doc/src/sgml/ref/dropdb.sgml
View file @ bf43bed8
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/ref/dropdb.sgml,v 1.13 2001/12/08 03:24:36 thomas Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/ref/dropdb.sgml,v 1.14 2002/01/20 22:19:56 petere Exp $
PostgreSQL documentation
-->
......@@ -40,7 +40,7 @@ PostgreSQL documentation
Specifies the host name of the machine on which the
server
is running. If host begins with a slash, it is used
as the directory for the unix domain socket.
as the directory for the Unix domain socket.
</para>
</listitem>
</varlistentry>
......@@ -193,7 +193,7 @@ PostgreSQL documentation
<informalexample>
<para>
To destroy the database <literal>demo</literal> using the
server on host eden, port 5000, with verification and a peek
server on host <literal>eden</literal>, port 5000, with verification and a peek
at the underlying query:
<screen>
<prompt>$ </prompt><userinput>dropdb -p 5000 -h eden -i -e demo</userinput>
......
doc/src/sgml/ref/dropuser.sgml
View file @ bf43bed8
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/ref/dropuser.sgml,v 1.15 2001/12/08 03:24:36 thomas Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/ref/dropuser.sgml,v 1.16 2002/01/20 22:19:56 petere Exp $
PostgreSQL documentation
-->
......@@ -184,7 +184,7 @@ PostgreSQL documentation
<informalexample>
<para>
To remove user <literal>joe</literal> using the postmaster on host
eden, port 5000, with verification and a peek at the underlying
<literal>eden</literal>, port 5000, with verification and a peek at the underlying
query:
<screen>
<prompt>$ </prompt><userinput>dropuser -p 5000 -h eden -i -e joe</userinput>
......
doc/src/sgml/ref/ecpg-ref.sgml
View file @ bf43bed8
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/ref/ecpg-ref.sgml,v 1.17 2002/01/18 20:32:54 momjian Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/ref/ecpg-ref.sgml,v 1.18 2002/01/20 22:19:56 petere Exp $
PostgreSQL documentation
-->
......@@ -84,7 +84,7 @@ PostgreSQL documentation
<term>-o <replaceable>outfile</replaceable></term>
<listitem>
<para>
Specifies that <application>ecpg</application> should write all its output to outfile.
Specifies that <application>ecpg</application> should write all its output to <replaceable>outfile</replaceable>.
If no such option is given the output is written to
<filename><replaceable>name</replaceable>.c</filename>,
assuming the input file was
......@@ -255,7 +255,7 @@ EXEC SQL INCLUDE sqlca;
The <literal>sqlca</literal> is in lowercase.
While SQL convention may be
followed, i.e., using uppercase to separate embedded SQL
from C statements, sqlca (which includes the <filename>sqlca.h</>
from C statements, <literal>sqlca</literal> (which includes the <filename>sqlca.h</>
header file) <emphasis>must</> be lowercase. This is because the
EXEC SQL prefix indicates that this inclusion will be parsed by
<application>ecpg</application>.
......@@ -268,7 +268,7 @@ EXEC SQL INCLUDE sqlca;
</note>
<para>
The sqlprint command is used with the EXEC SQL WHENEVER
The <literal>sqlprint</literal> command is used with the <literal>EXEC SQL WHENEVER</literal>
statement to turn on error handling throughout the
program:
......
doc/src/sgml/ref/grant.sgml
View file @ bf43bed8
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/ref/grant.sgml,v 1.18 2002/01/18 01:04:53 tgl Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/ref/grant.sgml,v 1.19 2002/01/20 22:19:57 petere Exp $
PostgreSQL documentation
-->
......@@ -216,7 +216,7 @@ GRANT INSERT ON films TO PUBLIC;
</para>
<para>
Grant all privileges to user manuel on view kinds:
Grant all privileges to user <literal>manuel</literal> on view <literal>kinds</literal>:
<programlisting>
GRANT ALL PRIVILEGES ON kinds TO manuel;
......
doc/src/sgml/ref/load.sgml
View file @ bf43bed8
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/ref/load.sgml,v 1.11 2001/11/18 20:35:02 petere Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/ref/load.sgml,v 1.12 2002/01/20 22:19:57 petere Exp $
-->
<refentry id="SQL-LOAD">
......@@ -33,10 +33,10 @@ LOAD '<replaceable class="PARAMETER">filename</replaceable>'
</para>
<para>
The filename is specified in the same way as for shared library
The file name is specified in the same way as for shared library
names in <xref linkend="sql-createfunction" endterm="sql-createfunction-title">; in particular, one
may rely on a search path and automatic addition of the system's standard
shared library filename extension. See the
shared library file name extension. See the
<citetitle>Programmer's Guide</citetitle> for more detail.
</para>
</refsect1>
......
doc/src/sgml/ref/pg_config-ref.sgml
View file @ bf43bed8
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/ref/pg_config-ref.sgml,v 1.8 2001/09/16 16:11:09 petere Exp $ -->
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/ref/pg_config-ref.sgml,v 1.9 2002/01/20 22:19:57 petere Exp $ -->
<refentry id="app-pgconfig">
<docinfo>
......@@ -50,7 +50,7 @@
To use <application>pg_config</>, supply one or more of the following options:
<variablelist>
<varlistentry>
<term>--bindir</>
<term><option>--bindir</option></>
<listitem>
<para>
Print the location of user executables. Use this, for example, to find
......@@ -61,7 +61,7 @@
</varlistentry>
<varlistentry>
<term>--includedir</>
<term><option>--includedir</option></>
<listitem>
<para>
Print the location of C and C++ header files of the client interfaces.
......@@ -70,7 +70,7 @@
</varlistentry>
<varlistentry>
<term>--includedir-server</>
<term><option>--includedir-server</option></>
<listitem>
<para>
Print the location of C and C++ header files for server
......@@ -80,7 +80,7 @@
</varlistentry>
<varlistentry>
<term>--libdir</>
<term><option>--libdir</option></>
<listitem>
<para>
Print the location of object code libraries.
......@@ -89,7 +89,7 @@
</varlistentry>
<varlistentry>
<term>--pkglibdir</>
<term><option>--pkglibdir</option></>
<listitem>
<para>
Print the location of dynamically loadable modules, or where
......@@ -101,7 +101,7 @@
</varlistentry>
<varlistentry>
<term>--configure</>
<term><option>--configure</option></>
<listitem>
<para>
Print the options that were given to the <filename>configure</>
......@@ -115,7 +115,7 @@
</varlistentry>
<varlistentry>
<term>--version</>
<term><option>--version</option></>
<listitem>
<para>
Print the version of <productname>PostgreSQL</> and exit.
......
doc/src/sgml/ref/select_into.sgml
View file @ bf43bed8
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/ref/select_into.sgml,v 1.15 2001/12/08 03:24:39 thomas Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/ref/select_into.sgml,v 1.16 2002/01/20 22:19:57 petere Exp $
PostgreSQL documentation
-->
......@@ -123,7 +123,7 @@ where <replaceable class="PARAMETER">from_item</replaceable> can be:
<command>SELECT INTO</command> creates a new table and fills it
with data computed by a query. The data is not returned to the
client, as it is with a normal <command>SELECT</command>. The new
table's columns have the names and datatypes associated with the
table's columns have the names and data types associated with the
output columns of the <command>SELECT</command>.
<note>
......@@ -132,7 +132,7 @@ where <replaceable class="PARAMETER">from_item</replaceable> can be:
is functionally equivalent to <command>SELECT INTO</command>.
<command>CREATE TABLE AS</command> is the recommended syntax, since
<command>SELECT INTO</command> is not standard. In fact, this form of
<command>SELECT INTO</command> is not available in PL/pgSQL or ecpg,
<command>SELECT INTO</command> is not available in <application>PL/pgSQL</application> or <xref linkend="app-ecpg">,
because they interpret the INTO clause differently.
</para>
</note>
......@@ -147,7 +147,7 @@ where <replaceable class="PARAMETER">from_item</replaceable> can be:
<para>
SQL92 uses <command>SELECT ... INTO</command> to represent selecting
values into scalar variables of a host program, rather than creating
a new table. This indeed is the usage found in PL/pgSQL and ecpg.
a new table. This indeed is the usage found in <application>PL/pgSQL</application> and <xref linkend="app-ecpg">.
The <productname>PostgreSQL</productname> usage of <command>SELECT
INTO</command> to represent table creation is historical. It's best
to use <command>CREATE TABLE AS</command> for this purpose in new code.
......
doc/src/sgml/ref/set_session_auth.sgml
View file @ bf43bed8
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/ref/set_session_auth.sgml,v 1.3 2001/11/18 20:35:02 petere Exp $ -->
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/ref/set_session_auth.sgml,v 1.4 2002/01/20 22:19:57 petere Exp $ -->
<refentry id="SQL-SET-SESSION-AUTHORIZATION">
<docinfo>
<date>2001-04-21</date>
......@@ -25,7 +25,7 @@ SET SESSION AUTHORIZATION '<parameter>username</parameter>'
<para>
This command sets the session user identifier and the current user
identifer of the current SQL-session context to be
identifier of the current SQL-session context to be
<parameter>username</parameter>.
</para>
......@@ -34,7 +34,7 @@ SET SESSION AUTHORIZATION '<parameter>username</parameter>'
authenticated) user name provided by the client. The current user
identifier is normally equal to the session user identifier, but
may change temporarily in the context of <quote>setuid</quote>
functions and similar mechanisms. The current user identifer is
functions and similar mechanisms. The current user identifier is
relevant for permission checking.
</para>
......
doc/src/sgml/ref/set_transaction.sgml
View file @ bf43bed8
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/ref/set_transaction.sgml,v 1.7 2001/12/08 03:24:39 thomas Exp $ -->
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/ref/set_transaction.sgml,v 1.8 2002/01/20 22:19:57 petere Exp $ -->
<refentry id="SQL-SET-TRANSACTION">
<docinfo>
<date>2000-11-24</date>
......@@ -29,7 +29,7 @@ SET SESSION CHARACTERISTICS AS TRANSACTION ISOLATION LEVEL
This command sets the transaction isolation level. The
<command>SET TRANSACTION</command> command sets the characteristics
for the current SQL-transaction. It has no effect on any subsequent
transactions. This command cannot be used after the first DML
transactions. This command cannot be used after the first query or data-modification
statement (<command>SELECT</command>, <command>INSERT</command>,
<command>DELETE</command>, <command>UPDATE</command>,
<command>FETCH</command>, <command>COPY</command>) of a transaction
......@@ -59,7 +59,7 @@ SET SESSION CHARACTERISTICS AS TRANSACTION ISOLATION LEVEL
<listitem>
<para>
The current transaction can only see rows committed before
first DML statement was executed in this transaction.
first query or data-modification statement was executed in this transaction.
</para>
<tip>
<para>
......@@ -101,7 +101,7 @@ SET default_transaction_isolation = '<replaceable>value</replaceable>'
<productname>PostgreSQL</productname> does not provide the
isolation levels <option>READ UNCOMMITTED</option>
and <option>REPEATABLE READ</option>. Because
of multi-version concurrency control, the serializable level is not
of multiversion concurrency control, the serializable level is not
truly serializable. See the <citetitle>User's Guide</citetitle> for
details.
</para>
......
doc/src/sgml/regress.sgml
View file @ bf43bed8
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/regress.sgml,v 1.24 2002/01/07 02:29:13 petere Exp $ -->
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/regress.sgml,v 1.25 2002/01/20 22:19:56 petere Exp $ -->
<chapter id="regress">
<title id="regress-title">Regression Tests</title>
......@@ -86,7 +86,7 @@
<tip>
<para>
The parallel regression test starts quite a few processes under your
userid. Presently, the maximum concurrency is twenty parallel test
user ID. Presently, the maximum concurrency is twenty parallel test
scripts, which means sixty processes --- there's a backend, a psql,
and usually a shell parent process for the psql for each test script.
So if your system enforces a per-user limit on the number of processes,
......
doc/src/sgml/release.sgml
View file @ bf43bed8
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/release.sgml,v 1.112 2002/01/09 00:52:37 petere Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/release.sgml,v 1.113 2002/01/20 22:19:56 petere Exp $
-->
<appendix id="release">
......@@ -182,7 +182,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/release.sgml,v 1.112 2002/01/09 00:52:37 pe
<title>Server Operation</title>
<literallayout>
Create temporary files in a separate directory (Bruce)
Delete orphanded temporary files on postmaster startup (Bruce)
Delete orphaned temporary files on postmaster startup (Bruce)
Added unique indexes to some system tables (Tom)
System table operator reorganization (Oleg Bartunov, Teodor Sigaev, Tom)
Renamed pg_log to pg_clog (Tom)
......@@ -268,7 +268,7 @@ New IS UNKNOWN, IS NOT UNKNOWN Boolean tests (Tom)
New SHARE UPDATE EXCLUSIVE lock mode (Tom)
New EXPLAIN ANALYZE command that shows run times and row counts (Martijn van Oosterhout)
Fix problem with LIMIT and subqueries (Tom)
Fix for LIMIT, DISTINCT ON pushed into subqueryies (Tom)
Fix for LIMIT, DISTINCT ON pushed into subqueries (Tom)
Fix nested EXCEPT/INTERSECT (Tom)
</literallayout>
</sect3>
......@@ -336,7 +336,7 @@ New TIMESTAMP WITHOUT TIMEZONE data type (Thomas)
Add ISO date/time specification with "T", yyyy-mm-ddThh:mm:ss (Thomas)
New xid/int comparison functions (Hiroshi)
Add precision to TIME, TIMESTAMP, and INVERVAL data types (Thomas)
Modify type coersion logic to attempt binary-compatible functions first (Tom)
Modify type coercion logic to attempt binary-compatible functions first (Tom)
New encode() function installed by default (Marko Kreen)
Improved to_*() conversion functions (Karel Zak)
Optimize LIKE/ILIKE when using single-byte encodings (Tatsuo)
......
doc/src/sgml/rules.sgml
View file @ bf43bed8
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/rules.sgml,v 1.20 2002/01/07 02:29:13 petere Exp $ -->
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/rules.sgml,v 1.21 2002/01/20 22:19:56 petere Exp $ -->
<Chapter Id="rules">
<Title>The Rule System</Title>
......@@ -282,15 +282,15 @@
between a
<ProgramListing>
CREATE VIEW myview AS SELECT * FROM mytab;
CREATE VIEW myview AS SELECT * FROM mytab;
</ProgramListing>
compared against the two commands
<ProgramListing>
CREATE TABLE myview (<Replaceable>same attribute list as for mytab</Replaceable>);
CREATE RULE "_RETmyview" AS ON SELECT TO myview DO INSTEAD
SELECT * FROM mytab;
CREATE TABLE myview (<Replaceable>same attribute list as for mytab</Replaceable>);
CREATE RULE "_RETmyview" AS ON SELECT TO myview DO INSTEAD
SELECT * FROM mytab;
</ProgramListing>
because this is exactly what the CREATE VIEW command does internally.
......@@ -342,14 +342,14 @@
integer values. We create that as
<ProgramListing>
CREATE FUNCTION min(integer, integer) RETURNS integer AS
'BEGIN
IF $1 < $2 THEN
RETURN $1;
END IF;
RETURN $2;
END;'
LANGUAGE 'plpgsql';
CREATE FUNCTION min(integer, integer) RETURNS integer AS '
BEGIN
IF $1 < $2 THEN
RETURN $1;
END IF;
RETURN $2;
END;
' LANGUAGE plpgsql;
</ProgramListing>
</Para>
......@@ -358,27 +358,27 @@
are these:
<ProgramListing>
CREATE TABLE shoe_data (
shoename char(10), -- primary key
sh_avail integer, -- available # of pairs
slcolor char(10), -- preferred shoelace color
slminlen float, -- miminum shoelace length
slmaxlen float, -- maximum shoelace length
slunit char(8) -- length unit
);
CREATE TABLE shoe_data (
shoename char(10), -- primary key
sh_avail integer, -- available # of pairs
slcolor char(10), -- preferred shoelace color
slminlen float, -- miminum shoelace length
slmaxlen float, -- maximum shoelace length
slunit char(8) -- length unit
);
CREATE TABLE shoelace_data (
sl_name char(10), -- primary key
sl_avail integer, -- available # of pairs
sl_color char(10), -- shoelace color
sl_len float, -- shoelace length
sl_unit char(8) -- length unit
);
CREATE TABLE shoelace_data (
sl_name char(10), -- primary key
sl_avail integer, -- available # of pairs
sl_color char(10), -- shoelace color
sl_len float, -- shoelace length
sl_unit char(8) -- length unit
);
CREATE TABLE unit (
un_name char(8), -- the primary key
un_fact float -- factor to transform to cm
);
CREATE TABLE unit (
un_name char(8), -- the primary key
un_fact float -- factor to transform to cm
);
</ProgramListing>
I think most of us wear shoes and can realize that this is
......@@ -391,38 +391,38 @@
The views are created as
<ProgramListing>
CREATE VIEW shoe AS
SELECT sh.shoename,
sh.sh_avail,
sh.slcolor,
sh.slminlen,
sh.slminlen * un.un_fact AS slminlen_cm,
sh.slmaxlen,
sh.slmaxlen * un.un_fact AS slmaxlen_cm,
sh.slunit
FROM shoe_data sh, unit un
WHERE sh.slunit = un.un_name;
CREATE VIEW shoelace AS
SELECT s.sl_name,
s.sl_avail,
s.sl_color,
s.sl_len,
s.sl_unit,
s.sl_len * u.un_fact AS sl_len_cm
FROM shoelace_data s, unit u
WHERE s.sl_unit = u.un_name;
CREATE VIEW shoe_ready AS
SELECT rsh.shoename,
rsh.sh_avail,
rsl.sl_name,
rsl.sl_avail,
min(rsh.sh_avail, rsl.sl_avail) AS total_avail
FROM shoe rsh, shoelace rsl
WHERE rsl.sl_color = rsh.slcolor
AND rsl.sl_len_cm >= rsh.slminlen_cm
AND rsl.sl_len_cm <= rsh.slmaxlen_cm;
CREATE VIEW shoe AS
SELECT sh.shoename,
sh.sh_avail,
sh.slcolor,
sh.slminlen,
sh.slminlen * un.un_fact AS slminlen_cm,
sh.slmaxlen,
sh.slmaxlen * un.un_fact AS slmaxlen_cm,
sh.slunit
FROM shoe_data sh, unit un
WHERE sh.slunit = un.un_name;
CREATE VIEW shoelace AS
SELECT s.sl_name,
s.sl_avail,
s.sl_color,
s.sl_len,
s.sl_unit,
s.sl_len * u.un_fact AS sl_len_cm
FROM shoelace_data s, unit u
WHERE s.sl_unit = u.un_name;
CREATE VIEW shoe_ready AS
SELECT rsh.shoename,
rsh.sh_avail,
rsl.sl_name,
rsl.sl_avail,
min(rsh.sh_avail, rsl.sl_avail) AS total_avail
FROM shoe rsh, shoelace rsl
WHERE rsl.sl_color = rsh.slcolor
AND rsl.sl_len_cm >= rsh.slminlen_cm
AND rsl.sl_len_cm <= rsh.slmaxlen_cm;
</ProgramListing>
The CREATE VIEW command for the <Filename>shoelace</Filename>
......@@ -457,60 +457,60 @@
SELECT in his life:
<ProgramListing>
al_bundy=> INSERT INTO unit VALUES ('cm', 1.0);
al_bundy=> INSERT INTO unit VALUES ('m', 100.0);
al_bundy=> INSERT INTO unit VALUES ('inch', 2.54);
al_bundy=>
al_bundy=> INSERT INTO shoe_data VALUES
al_bundy-> ('sh1', 2, 'black', 70.0, 90.0, 'cm');
al_bundy=> INSERT INTO shoe_data VALUES
al_bundy-> ('sh2', 0, 'black', 30.0, 40.0, 'inch');
al_bundy=> INSERT INTO shoe_data VALUES
al_bundy-> ('sh3', 4, 'brown', 50.0, 65.0, 'cm');
al_bundy=> INSERT INTO shoe_data VALUES
al_bundy-> ('sh4', 3, 'brown', 40.0, 50.0, 'inch');
al_bundy=>
al_bundy=> INSERT INTO shoelace_data VALUES
al_bundy-> ('sl1', 5, 'black', 80.0, 'cm');
al_bundy=> INSERT INTO shoelace_data VALUES
al_bundy-> ('sl2', 6, 'black', 100.0, 'cm');
al_bundy=> INSERT INTO shoelace_data VALUES
al_bundy-> ('sl3', 0, 'black', 35.0 , 'inch');
al_bundy=> INSERT INTO shoelace_data VALUES
al_bundy-> ('sl4', 8, 'black', 40.0 , 'inch');
al_bundy=> INSERT INTO shoelace_data VALUES
al_bundy-> ('sl5', 4, 'brown', 1.0 , 'm');
al_bundy=> INSERT INTO shoelace_data VALUES
al_bundy-> ('sl6', 0, 'brown', 0.9 , 'm');
al_bundy=> INSERT INTO shoelace_data VALUES
al_bundy-> ('sl7', 7, 'brown', 60 , 'cm');
al_bundy=> INSERT INTO shoelace_data VALUES
al_bundy-> ('sl8', 1, 'brown', 40 , 'inch');
al_bundy=>
al_bundy=> SELECT * FROM shoelace;
sl_name |sl_avail|sl_color |sl_len|sl_unit |sl_len_cm
----------+--------+----------+------+--------+---------
sl1 | 5|black | 80|cm | 80
sl2 | 6|black | 100|cm | 100
sl7 | 7|brown | 60|cm | 60
sl3 | 0|black | 35|inch | 88.9
sl4 | 8|black | 40|inch | 101.6
sl8 | 1|brown | 40|inch | 101.6
sl5 | 4|brown | 1|m | 100
sl6 | 0|brown | 0.9|m | 90
(8 rows)
al_bundy=> INSERT INTO unit VALUES ('cm', 1.0);
al_bundy=> INSERT INTO unit VALUES ('m', 100.0);
al_bundy=> INSERT INTO unit VALUES ('inch', 2.54);
al_bundy=>
al_bundy=> INSERT INTO shoe_data VALUES
al_bundy-> ('sh1', 2, 'black', 70.0, 90.0, 'cm');
al_bundy=> INSERT INTO shoe_data VALUES
al_bundy-> ('sh2', 0, 'black', 30.0, 40.0, 'inch');
al_bundy=> INSERT INTO shoe_data VALUES
al_bundy-> ('sh3', 4, 'brown', 50.0, 65.0, 'cm');
al_bundy=> INSERT INTO shoe_data VALUES
al_bundy-> ('sh4', 3, 'brown', 40.0, 50.0, 'inch');
al_bundy=>
al_bundy=> INSERT INTO shoelace_data VALUES
al_bundy-> ('sl1', 5, 'black', 80.0, 'cm');
al_bundy=> INSERT INTO shoelace_data VALUES
al_bundy-> ('sl2', 6, 'black', 100.0, 'cm');
al_bundy=> INSERT INTO shoelace_data VALUES
al_bundy-> ('sl3', 0, 'black', 35.0 , 'inch');
al_bundy=> INSERT INTO shoelace_data VALUES
al_bundy-> ('sl4', 8, 'black', 40.0 , 'inch');
al_bundy=> INSERT INTO shoelace_data VALUES
al_bundy-> ('sl5', 4, 'brown', 1.0 , 'm');
al_bundy=> INSERT INTO shoelace_data VALUES
al_bundy-> ('sl6', 0, 'brown', 0.9 , 'm');
al_bundy=> INSERT INTO shoelace_data VALUES
al_bundy-> ('sl7', 7, 'brown', 60 , 'cm');
al_bundy=> INSERT INTO shoelace_data VALUES
al_bundy-> ('sl8', 1, 'brown', 40 , 'inch');
al_bundy=>
al_bundy=> SELECT * FROM shoelace;
sl_name |sl_avail|sl_color |sl_len|sl_unit |sl_len_cm
----------+--------+----------+------+--------+---------
sl1 | 5|black | 80|cm | 80
sl2 | 6|black | 100|cm | 100
sl7 | 7|brown | 60|cm | 60
sl3 | 0|black | 35|inch | 88.9
sl4 | 8|black | 40|inch | 101.6
sl8 | 1|brown | 40|inch | 101.6
sl5 | 4|brown | 1|m | 100
sl6 | 0|brown | 0.9|m | 90
(8 rows)
</ProgramListing>
It's the simplest SELECT Al can do on our views, so we take this
to explain the basics of view rules.
The <literal>SELECT * FROM shoelace</literal> was interpreted by the parser and
produced the parsetree
produced the parse tree
<ProgramListing>
SELECT shoelace.sl_name, shoelace.sl_avail,
shoelace.sl_color, shoelace.sl_len,
shoelace.sl_unit, shoelace.sl_len_cm
FROM shoelace shoelace;
SELECT shoelace.sl_name, shoelace.sl_avail,
shoelace.sl_color, shoelace.sl_len,
shoelace.sl_unit, shoelace.sl_len_cm
FROM shoelace shoelace;
</ProgramListing>
and this is given to the rule system. The rule system walks through the
......@@ -520,12 +520,12 @@
rule <literal>_RETshoelace</literal> with the parse tree
<ProgramListing>
<FirstTerm>SELECT s.sl_name, s.sl_avail,
s.sl_color, s.sl_len, s.sl_unit,
float8mul(s.sl_len, u.un_fact) AS sl_len_cm
FROM shoelace *OLD*, shoelace *NEW*,
shoelace_data s, unit u
WHERE bpchareq(s.sl_unit, u.un_name);</FirstTerm>
<emphasis>SELECT s.sl_name, s.sl_avail,
s.sl_color, s.sl_len, s.sl_unit,
float8mul(s.sl_len, u.un_fact) AS sl_len_cm
FROM shoelace *OLD*, shoelace *NEW*,
shoelace_data s, unit u
WHERE bpchareq(s.sl_unit, u.un_name);</emphasis>
</ProgramListing>
Note that the parser changed the calculation and qualification into
......@@ -534,23 +534,23 @@
</Para>
<Para>
To expand the view, the rewriter simply creates a subselect rangetable
entry containing the rule's action parsetree, and substitutes this
To expand the view, the rewriter simply creates a subselect range-table
entry containing the rule's action parse tree, and substitutes this
range table entry for the original one that referenced the view. The
resulting rewritten parse tree is almost the same as if Al had typed
<ProgramListing>
SELECT shoelace.sl_name, shoelace.sl_avail,
shoelace.sl_color, shoelace.sl_len,
shoelace.sl_unit, shoelace.sl_len_cm
FROM (SELECT s.sl_name,
s.sl_avail,
s.sl_color,
s.sl_len,
s.sl_unit,
s.sl_len * u.un_fact AS sl_len_cm
FROM shoelace_data s, unit u
WHERE s.sl_unit = u.un_name) shoelace;
SELECT shoelace.sl_name, shoelace.sl_avail,
shoelace.sl_color, shoelace.sl_len,
shoelace.sl_unit, shoelace.sl_len_cm
FROM (SELECT s.sl_name,
s.sl_avail,
s.sl_color,
s.sl_len,
s.sl_unit,
s.sl_len * u.un_fact AS sl_len_cm
FROM shoelace_data s, unit u
WHERE s.sl_unit = u.un_name) shoelace;
</ProgramListing>
There is one difference however: the sub-query's range table has two
......@@ -558,7 +558,7 @@
participate directly in the query, since they aren't referenced by
the sub-query's join tree or target list. The rewriter uses them
to store the access permission check info that was originally present
in the rangetable entry that referenced the view. In this way, the
in the range-table entry that referenced the view. In this way, the
executor will still check that the user has proper permissions to access
the view, even though there's no direct use of the view in the rewritten
query.
......@@ -566,8 +566,8 @@
<Para>
That was the first rule applied. The rule system will continue checking
the remaining rangetable entries in the top query (in this example there
are no more), and it will recursively check the rangetable entries in
the remaining range-table entries in the top query (in this example there
are no more), and it will recursively check the range-table entries in
the added sub-query to see if any of them reference views. (But it
won't expand *OLD* or *NEW* --- otherwise we'd have infinite recursion!)
In this example, there are no rewrite rules for shoelace_data or unit,
......@@ -590,12 +590,12 @@
We teach him what to do and he asks his database:
<ProgramListing>
al_bundy=> SELECT * FROM shoe_ready WHERE total_avail >= 2;
shoename |sh_avail|sl_name |sl_avail|total_avail
----------+--------+----------+--------+-----------
sh1 | 2|sl1 | 5| 2
sh3 | 4|sl7 | 7| 4
(2 rows)
al_bundy=> SELECT * FROM shoe_ready WHERE total_avail >= 2;
shoename |sh_avail|sl_name |sl_avail|total_avail
----------+--------+----------+--------+-----------
sh1 | 2|sl1 | 5| 2
sh3 | 4|sl7 | 7| 4
(2 rows)
</ProgramListing>
Al is a shoe guru and so he knows that only shoes of type sh1
......@@ -607,11 +607,11 @@
The output of the parser this time is the parse tree
<ProgramListing>
SELECT shoe_ready.shoename, shoe_ready.sh_avail,
shoe_ready.sl_name, shoe_ready.sl_avail,
shoe_ready.total_avail
FROM shoe_ready shoe_ready
WHERE int4ge(shoe_ready.total_avail, 2);
SELECT shoe_ready.shoename, shoe_ready.sh_avail,
shoe_ready.sl_name, shoe_ready.sl_avail,
shoe_ready.total_avail
FROM shoe_ready shoe_ready
WHERE int4ge(shoe_ready.total_avail, 2);
</ProgramListing>
The first rule applied will be the one for the
......@@ -619,19 +619,19 @@
parse tree
<ProgramListing>
SELECT shoe_ready.shoename, shoe_ready.sh_avail,
shoe_ready.sl_name, shoe_ready.sl_avail,
shoe_ready.total_avail
FROM (SELECT rsh.shoename,
rsh.sh_avail,
rsl.sl_name,
rsl.sl_avail,
min(rsh.sh_avail, rsl.sl_avail) AS total_avail
FROM shoe rsh, shoelace rsl
WHERE rsl.sl_color = rsh.slcolor
AND rsl.sl_len_cm >= rsh.slminlen_cm
AND rsl.sl_len_cm <= rsh.slmaxlen_cm) shoe_ready
WHERE int4ge(shoe_ready.total_avail, 2);
SELECT shoe_ready.shoename, shoe_ready.sh_avail,
shoe_ready.sl_name, shoe_ready.sl_avail,
shoe_ready.total_avail
FROM (SELECT rsh.shoename,
rsh.sh_avail,
rsl.sl_name,
rsl.sl_avail,
min(rsh.sh_avail, rsl.sl_avail) AS total_avail
FROM shoe rsh, shoelace rsl
WHERE rsl.sl_color = rsh.slcolor
AND rsl.sl_len_cm >= rsh.slminlen_cm
AND rsl.sl_len_cm <= rsh.slmaxlen_cm) shoe_ready
WHERE int4ge(shoe_ready.total_avail, 2);
</ProgramListing>
Similarly, the rules for <Filename>shoe</Filename> and
......@@ -639,36 +639,36 @@
the sub-query, leading to a three-level final query tree:
<ProgramListing>
SELECT shoe_ready.shoename, shoe_ready.sh_avail,
shoe_ready.sl_name, shoe_ready.sl_avail,
shoe_ready.total_avail
FROM (SELECT rsh.shoename,
rsh.sh_avail,
rsl.sl_name,
rsl.sl_avail,
min(rsh.sh_avail, rsl.sl_avail) AS total_avail
FROM (SELECT sh.shoename,
sh.sh_avail,
sh.slcolor,
sh.slminlen,
sh.slminlen * un.un_fact AS slminlen_cm,
sh.slmaxlen,
sh.slmaxlen * un.un_fact AS slmaxlen_cm,
sh.slunit
FROM shoe_data sh, unit un
WHERE sh.slunit = un.un_name) rsh,
(SELECT s.sl_name,
s.sl_avail,
s.sl_color,
s.sl_len,
s.sl_unit,
s.sl_len * u.un_fact AS sl_len_cm
FROM shoelace_data s, unit u
WHERE s.sl_unit = u.un_name) rsl
WHERE rsl.sl_color = rsh.slcolor
AND rsl.sl_len_cm >= rsh.slminlen_cm
AND rsl.sl_len_cm <= rsh.slmaxlen_cm) shoe_ready
WHERE int4ge(shoe_ready.total_avail, 2);
SELECT shoe_ready.shoename, shoe_ready.sh_avail,
shoe_ready.sl_name, shoe_ready.sl_avail,
shoe_ready.total_avail
FROM (SELECT rsh.shoename,
rsh.sh_avail,
rsl.sl_name,
rsl.sl_avail,
min(rsh.sh_avail, rsl.sl_avail) AS total_avail
FROM (SELECT sh.shoename,
sh.sh_avail,
sh.slcolor,
sh.slminlen,
sh.slminlen * un.un_fact AS slminlen_cm,
sh.slmaxlen,
sh.slmaxlen * un.un_fact AS slmaxlen_cm,
sh.slunit
FROM shoe_data sh, unit un
WHERE sh.slunit = un.un_name) rsh,
(SELECT s.sl_name,
s.sl_avail,
s.sl_color,
s.sl_len,
s.sl_unit,
s.sl_len * u.un_fact AS sl_len_cm
FROM shoelace_data s, unit u
WHERE s.sl_unit = u.un_name) rsl
WHERE rsl.sl_color = rsh.slcolor
AND rsl.sl_len_cm >= rsh.slminlen_cm
AND rsl.sl_len_cm <= rsh.slmaxlen_cm) shoe_ready
WHERE int4ge(shoe_ready.total_avail, 2);
</ProgramListing>
It turns out that the planner will collapse this tree into a two-level
......@@ -718,9 +718,9 @@
a and b, the parse trees for the two statements
<ProgramListing>
SELECT t2.b FROM t1, t2 WHERE t1.a = t2.a;
SELECT t2.b FROM t1, t2 WHERE t1.a = t2.a;
UPDATE t1 SET b = t2.b WHERE t1.a = t2.a;
UPDATE t1 SET b = t2.b WHERE t1.a = t2.a;
</ProgramListing>
are nearly identical.
......@@ -759,14 +759,14 @@
and the final parse tree will read as
<ProgramListing>
UPDATE t1 SET a = t1.a, b = t2.b WHERE t1.a = t2.a;
UPDATE t1 SET a = t1.a, b = t2.b WHERE t1.a = t2.a;
</ProgramListing>
and thus the executor run over the join will produce exactly the
same result set as a
<ProgramListing>
SELECT t1.a, t2.b FROM t1, t2 WHERE t1.a = t2.a;
SELECT t1.a, t2.b FROM t1, t2 WHERE t1.a = t2.a;
</ProgramListing>
will do. But there is a little problem in UPDATE. The executor does
......@@ -781,21 +781,21 @@
<Para>
To resolve this problem, another entry is added to the target list
in UPDATE (and also in DELETE) statements: the current tuple ID (ctid).
in UPDATE (and also in DELETE) statements: the current tuple ID (CTID).
This is a system attribute containing the file
block number and position in the block for the row. Knowing the table,
the ctid can be used to retrieve the original t1 row to be updated.
After adding the ctid to the target list, the query actually looks like
the CTID can be used to retrieve the original t1 row to be updated.
After adding the CTID to the target list, the query actually looks like
<ProgramListing>
SELECT t1.a, t2.b, t1.ctid FROM t1, t2 WHERE t1.a = t2.a;
SELECT t1.a, t2.b, t1.ctid FROM t1, t2 WHERE t1.a = t2.a;
</ProgramListing>
Now another detail of <ProductName>PostgreSQL</ProductName> enters the
stage. At this moment, table rows aren't overwritten and this is why
ABORT TRANSACTION is fast. In an UPDATE, the new result row is inserted
into the table (after stripping ctid) and in the tuple header of the row
that ctid pointed to the cmax and xmax entries are set to the current
into the table (after stripping CTID) and in the tuple header of the row
that CTID pointed to the cmax and xmax entries are set to the current
command counter and current transaction ID. Thus the old row is hidden
and after the transaction committed the vacuum cleaner can really move
it out.
......@@ -915,9 +915,9 @@
Keep the syntax
<ProgramListing>
CREATE RULE rule_name AS ON event
TO object [WHERE rule_qualification]
DO [INSTEAD] [action | (actions) | NOTHING];
CREATE RULE rule_name AS ON event
TO object [WHERE rule_qualification]
DO [INSTEAD] [action | (actions) | NOTHING];
</ProgramListing>
in mind.
......@@ -1046,20 +1046,20 @@
</Para>
<Para>
The parsetrees found in the actions of the <Filename>pg_rewrite</Filename>
The parse trees found in the actions of the <Filename>pg_rewrite</Filename>
system catalog are only templates. Since they can reference the
rangetable entries for NEW and OLD, some substitutions have to be made
before they can be used. For any reference to NEW, the targetlist of
range-table entries for NEW and OLD, some substitutions have to be made
before they can be used. For any reference to NEW, the target list of
the original query is searched for a corresponding entry. If found,
that entry's expression replaces the reference. Otherwise
NEW means the same as OLD (for an UPDATE) or is replaced by NULL
(for an INSERT). Any reference to OLD is replaced by a
reference to the rangetable entry which is the resultrelation.
reference to the range-table entry which is the result relation.
</Para>
<Para>
After we are done applying update rules, we apply view rules to the
produced parsetree(s). Views cannot insert new update actions so
produced parse tree(s). Views cannot insert new update actions so
there is no need to apply update rules to the output of view rewriting.
</Para>
......@@ -1073,21 +1073,21 @@
an UPDATE is performed on <Filename>shoelace_data</Filename>.
<ProgramListing>
CREATE TABLE shoelace_log (
sl_name char(10), -- shoelace changed
sl_avail integer, -- new available value
log_who text, -- who did it
log_when timestamp -- when
);
CREATE TABLE shoelace_log (
sl_name char(10), -- shoelace changed
sl_avail integer, -- new available value
log_who text, -- who did it
log_when timestamp -- when
);
CREATE RULE log_shoelace AS ON UPDATE TO shoelace_data
WHERE NEW.sl_avail != OLD.sl_avail
DO INSERT INTO shoelace_log VALUES (
NEW.sl_name,
NEW.sl_avail,
current_user,
current_timestamp
);
CREATE RULE log_shoelace AS ON UPDATE TO shoelace_data
WHERE NEW.sl_avail != OLD.sl_avail
DO INSERT INTO shoelace_log VALUES (
NEW.sl_name,
NEW.sl_avail,
current_user,
current_timestamp
);
</ProgramListing>
</Para>
......@@ -1095,50 +1095,50 @@
Now Al does
<ProgramListing>
al_bundy=> UPDATE shoelace_data SET sl_avail = 6
al_bundy-> WHERE sl_name = 'sl7';
al_bundy=> UPDATE shoelace_data SET sl_avail = 6
al_bundy-> WHERE sl_name = 'sl7';
</ProgramListing>
and we look at the logtable.
and we look at the log table.
<ProgramListing>
al_bundy=> SELECT * FROM shoelace_log;
sl_name |sl_avail|log_who|log_when
----------+--------+-------+--------------------------------
sl7 | 6|Al |Tue Oct 20 16:14:45 1998 MET DST
(1 row)
al_bundy=> SELECT * FROM shoelace_log;
sl_name |sl_avail|log_who|log_when
----------+--------+-------+--------------------------------
sl7 | 6|Al |Tue Oct 20 16:14:45 1998 MET DST
(1 row)
</ProgramListing>
That's what we expected. What happened in the background is the following.
The parser created the parsetree (this time the parts of the original
parsetree are highlighted because the base of operations is the
The parser created the parse tree (this time the parts of the original
parse tree are highlighted because the base of operations is the
rule action for update rules).
<ProgramListing>
<FirstTerm>UPDATE shoelace_data SET sl_avail = 6
FROM shoelace_data shoelace_data
WHERE bpchareq(shoelace_data.sl_name, 'sl7');</FirstTerm>
<emphasis>UPDATE shoelace_data SET sl_avail = 6
FROM shoelace_data shoelace_data
WHERE bpchareq(shoelace_data.sl_name, 'sl7');</emphasis>
</ProgramListing>
There is a rule <literal>log_shoelace</literal> that is ON UPDATE with the rule
qualification expression
<ProgramListing>
int4ne(NEW.sl_avail, OLD.sl_avail)
int4ne(NEW.sl_avail, OLD.sl_avail)
</ProgramListing>
and one action
<ProgramListing>
INSERT INTO shoelace_log VALUES(
*NEW*.sl_name, *NEW*.sl_avail,
current_user, current_timestamp
FROM shoelace_data *NEW*, shoelace_data *OLD*;
INSERT INTO shoelace_log VALUES(
*NEW*.sl_name, *NEW*.sl_avail,
current_user, current_timestamp
FROM shoelace_data *NEW*, shoelace_data *OLD*;
</ProgramListing>
This is a little strange-looking since you can't normally write
INSERT ... VALUES ... FROM. The FROM clause here is just to indicate
that there are rangetable entries in the parsetree for *NEW* and *OLD*.
that there are range-table entries in the parse tree for *NEW* and *OLD*.
These are needed so that they can be referenced by variables in the
INSERT command's querytree.
</Para>
......@@ -1146,27 +1146,27 @@
<Para>
The rule is a qualified non-INSTEAD rule, so the rule system
has to return two parse trees: the modified rule action and the original
parsetree. In the first step the range table of the original query is
parse tree. In the first step the range table of the original query is
incorporated into the rule's action parse tree. This results in
<ProgramListing>
INSERT INTO shoelace_log VALUES(
*NEW*.sl_name, *NEW*.sl_avail,
current_user, current_timestamp
FROM shoelace_data *NEW*, shoelace_data *OLD*,
<FirstTerm>shoelace_data shoelace_data</FirstTerm>;
INSERT INTO shoelace_log VALUES(
*NEW*.sl_name, *NEW*.sl_avail,
current_user, current_timestamp
FROM shoelace_data *NEW*, shoelace_data *OLD*,
<emphasis>shoelace_data shoelace_data</emphasis>;
</ProgramListing>
In step 2 the rule qualification is added to it, so the result set
is restricted to rows where sl_avail changes.
<ProgramListing>
INSERT INTO shoelace_log VALUES(
*NEW*.sl_name, *NEW*.sl_avail,
current_user, current_timestamp
FROM shoelace_data *NEW*, shoelace_data *OLD*,
shoelace_data shoelace_data
<FirstTerm>WHERE int4ne(*NEW*.sl_avail, *OLD*.sl_avail)</FirstTerm>;
INSERT INTO shoelace_log VALUES(
*NEW*.sl_name, *NEW*.sl_avail,
current_user, current_timestamp
FROM shoelace_data *NEW*, shoelace_data *OLD*,
shoelace_data shoelace_data
<emphasis>WHERE int4ne(*NEW*.sl_avail, *OLD*.sl_avail)</emphasis>;
</ProgramListing>
This is even stranger-looking, since INSERT ... VALUES doesn't have
......@@ -1179,13 +1179,13 @@
by the original parse tree.
<ProgramListing>
INSERT INTO shoelace_log VALUES(
*NEW*.sl_name, *NEW*.sl_avail,
current_user, current_timestamp
FROM shoelace_data *NEW*, shoelace_data *OLD*,
shoelace_data shoelace_data
WHERE int4ne(*NEW*.sl_avail, *OLD*.sl_avail)
<FirstTerm>AND bpchareq(shoelace_data.sl_name, 'sl7')</FirstTerm>;
INSERT INTO shoelace_log VALUES(
*NEW*.sl_name, *NEW*.sl_avail,
current_user, current_timestamp
FROM shoelace_data *NEW*, shoelace_data *OLD*,
shoelace_data shoelace_data
WHERE int4ne(*NEW*.sl_avail, *OLD*.sl_avail)
<emphasis>AND bpchareq(shoelace_data.sl_name, 'sl7')</emphasis>;
</ProgramListing>
Step 4 substitutes NEW references by the target list entries from the
......@@ -1193,25 +1193,25 @@
from the result relation.
<ProgramListing>
INSERT INTO shoelace_log VALUES(
<FirstTerm>shoelace_data.sl_name</FirstTerm>, <FirstTerm>6</FirstTerm>,
current_user, current_timestamp
FROM shoelace_data *NEW*, shoelace_data *OLD*,
shoelace_data shoelace_data
WHERE int4ne(<FirstTerm>6</FirstTerm>, *OLD*.sl_avail)
AND bpchareq(shoelace_data.sl_name, 'sl7');
INSERT INTO shoelace_log VALUES(
<emphasis>shoelace_data.sl_name</emphasis>, <emphasis>6</emphasis>,
current_user, current_timestamp
FROM shoelace_data *NEW*, shoelace_data *OLD*,
shoelace_data shoelace_data
WHERE int4ne(<emphasis>6</emphasis>, *OLD*.sl_avail)
AND bpchareq(shoelace_data.sl_name, 'sl7');
</ProgramListing>
Step 5 changes OLD references into result relation references.
<ProgramListing>
INSERT INTO shoelace_log VALUES(
shoelace_data.sl_name, 6,
current_user, current_timestamp
FROM shoelace_data *NEW*, shoelace_data *OLD*,
shoelace_data shoelace_data
WHERE int4ne(6, <FirstTerm>shoelace_data.sl_avail</FirstTerm>)
AND bpchareq(shoelace_data.sl_name, 'sl7');
INSERT INTO shoelace_log VALUES(
shoelace_data.sl_name, 6,
current_user, current_timestamp
FROM shoelace_data *NEW*, shoelace_data *OLD*,
shoelace_data shoelace_data
WHERE int4ne(6, <emphasis>shoelace_data.sl_avail</emphasis>)
AND bpchareq(shoelace_data.sl_name, 'sl7');
</ProgramListing>
That's it. Since the rule is not INSTEAD, we also output the
......@@ -1219,15 +1219,15 @@
is a list of two parse trees that are the same as the statements:
<ProgramListing>
INSERT INTO shoelace_log VALUES(
shoelace_data.sl_name, 6,
current_user, current_timestamp
FROM shoelace_data
WHERE 6 != shoelace_data.sl_avail
AND shoelace_data.sl_name = 'sl7';
INSERT INTO shoelace_log VALUES(
shoelace_data.sl_name, 6,
current_user, current_timestamp
FROM shoelace_data
WHERE 6 != shoelace_data.sl_avail
AND shoelace_data.sl_name = 'sl7';
UPDATE shoelace_data SET sl_avail = 6
WHERE sl_name = 'sl7';
UPDATE shoelace_data SET sl_avail = 6
WHERE sl_name = 'sl7';
</ProgramListing>
These are executed in this order and that is exactly what
......@@ -1235,8 +1235,8 @@
added ensure that if the original query would be, say,
<ProgramListing>
UPDATE shoelace_data SET sl_color = 'green'
WHERE sl_name = 'sl7';
UPDATE shoelace_data SET sl_color = 'green'
WHERE sl_name = 'sl7';
</ProgramListing>
no log entry would get written. This
......@@ -1245,12 +1245,12 @@
shoelace_data.sl_avail resulting in the extra query
<ProgramListing>
INSERT INTO shoelace_log VALUES(
shoelace_data.sl_name, <FirstTerm>shoelace_data.sl_avail</FirstTerm>,
current_user, current_timestamp)
FROM shoelace_data
WHERE <FirstTerm>shoelace_data.sl_avail</FirstTerm> != shoelace_data.sl_avail
AND shoelace_data.sl_name = 'sl7';
INSERT INTO shoelace_log VALUES(
shoelace_data.sl_name, <emphasis>shoelace_data.sl_avail</emphasis>,
current_user, current_timestamp)
FROM shoelace_data
WHERE <emphasis>shoelace_data.sl_avail</emphasis> != shoelace_data.sl_avail
AND shoelace_data.sl_name = 'sl7';
</ProgramListing>
and that qualification will never be true. It will also
......@@ -1258,8 +1258,8 @@
would issue the command
<ProgramListing>
UPDATE shoelace_data SET sl_avail = 0
WHERE sl_color = 'black';
UPDATE shoelace_data SET sl_avail = 0
WHERE sl_color = 'black';
</ProgramListing>
four rows in fact get updated (sl1, sl2, sl3 and sl4).
......@@ -1268,12 +1268,12 @@
in the extra parse tree
<ProgramListing>
INSERT INTO shoelace_log SELECT
shoelace_data.sl_name, 0,
current_user, current_timestamp
FROM shoelace_data
WHERE 0 != shoelace_data.sl_avail
AND <FirstTerm>shoelace_data.sl_color = 'black'</FirstTerm>;
INSERT INTO shoelace_log SELECT
shoelace_data.sl_name, 0,
current_user, current_timestamp
FROM shoelace_data
WHERE 0 != shoelace_data.sl_avail
AND <emphasis>shoelace_data.sl_color = 'black'</emphasis>;
</ProgramListing>
This parse tree will surely insert three new log entries. And
......@@ -1301,12 +1301,12 @@
thrown away. We create the rules
<ProgramListing>
CREATE RULE shoe_ins_protect AS ON INSERT TO shoe
DO INSTEAD NOTHING;
CREATE RULE shoe_upd_protect AS ON UPDATE TO shoe
DO INSTEAD NOTHING;
CREATE RULE shoe_del_protect AS ON DELETE TO shoe
DO INSTEAD NOTHING;
CREATE RULE shoe_ins_protect AS ON INSERT TO shoe
DO INSTEAD NOTHING;
CREATE RULE shoe_upd_protect AS ON UPDATE TO shoe
DO INSTEAD NOTHING;
CREATE RULE shoe_del_protect AS ON DELETE TO shoe
DO INSTEAD NOTHING;
</ProgramListing>
If Al now tries to do any of these operations on the view
......@@ -1338,29 +1338,29 @@
the following rules:
<ProgramListing>
CREATE RULE shoelace_ins AS ON INSERT TO shoelace
DO INSTEAD
INSERT INTO shoelace_data VALUES (
NEW.sl_name,
NEW.sl_avail,
NEW.sl_color,
NEW.sl_len,
NEW.sl_unit);
CREATE RULE shoelace_ins AS ON INSERT TO shoelace
DO INSTEAD
INSERT INTO shoelace_data VALUES (
NEW.sl_name,
NEW.sl_avail,
NEW.sl_color,
NEW.sl_len,
NEW.sl_unit);
CREATE RULE shoelace_upd AS ON UPDATE TO shoelace
DO INSTEAD
UPDATE shoelace_data SET
sl_name = NEW.sl_name,
sl_avail = NEW.sl_avail,
sl_color = NEW.sl_color,
sl_len = NEW.sl_len,
sl_unit = NEW.sl_unit
WHERE sl_name = OLD.sl_name;
CREATE RULE shoelace_upd AS ON UPDATE TO shoelace
DO INSTEAD
UPDATE shoelace_data SET
sl_name = NEW.sl_name,
sl_avail = NEW.sl_avail,
sl_color = NEW.sl_color,
sl_len = NEW.sl_len,
sl_unit = NEW.sl_unit
WHERE sl_name = OLD.sl_name;
CREATE RULE shoelace_del AS ON DELETE TO shoelace
DO INSTEAD
DELETE FROM shoelace_data
WHERE sl_name = OLD.sl_name;
CREATE RULE shoelace_del AS ON DELETE TO shoelace
DO INSTEAD
DELETE FROM shoelace_data
WHERE sl_name = OLD.sl_name;
</ProgramListing>
Now there is a pack of shoelaces arriving in Al's shop and it has
......@@ -1371,83 +1371,83 @@
trick. The create commands for these are:
<ProgramListing>
CREATE TABLE shoelace_arrive (
arr_name char(10),
arr_quant integer
);
CREATE TABLE shoelace_arrive (
arr_name char(10),
arr_quant integer
);
CREATE TABLE shoelace_ok (
ok_name char(10),
ok_quant integer
);
CREATE TABLE shoelace_ok (
ok_name char(10),
ok_quant integer
);
CREATE RULE shoelace_ok_ins AS ON INSERT TO shoelace_ok
DO INSTEAD
UPDATE shoelace SET
sl_avail = sl_avail + NEW.ok_quant
WHERE sl_name = NEW.ok_name;
CREATE RULE shoelace_ok_ins AS ON INSERT TO shoelace_ok
DO INSTEAD
UPDATE shoelace SET
sl_avail = sl_avail + NEW.ok_quant
WHERE sl_name = NEW.ok_name;
</ProgramListing>
Now Al can sit down and do whatever until
<ProgramListing>
al_bundy=> SELECT * FROM shoelace_arrive;
arr_name |arr_quant
----------+---------
sl3 | 10
sl6 | 20
sl8 | 20
(3 rows)
al_bundy=> SELECT * FROM shoelace_arrive;
arr_name |arr_quant
----------+---------
sl3 | 10
sl6 | 20
sl8 | 20
(3 rows)
</ProgramListing>
is exactly what's on the part list. We take a quick look
at the current data,
<ProgramListing>
al_bundy=> SELECT * FROM shoelace;
sl_name |sl_avail|sl_color |sl_len|sl_unit |sl_len_cm
----------+--------+----------+------+--------+---------
sl1 | 5|black | 80|cm | 80
sl2 | 6|black | 100|cm | 100
sl7 | 6|brown | 60|cm | 60
sl3 | 0|black | 35|inch | 88.9
sl4 | 8|black | 40|inch | 101.6
sl8 | 1|brown | 40|inch | 101.6
sl5 | 4|brown | 1|m | 100
sl6 | 0|brown | 0.9|m | 90
(8 rows)
al_bundy=> SELECT * FROM shoelace;
sl_name |sl_avail|sl_color |sl_len|sl_unit |sl_len_cm
----------+--------+----------+------+--------+---------
sl1 | 5|black | 80|cm | 80
sl2 | 6|black | 100|cm | 100
sl7 | 6|brown | 60|cm | 60
sl3 | 0|black | 35|inch | 88.9
sl4 | 8|black | 40|inch | 101.6
sl8 | 1|brown | 40|inch | 101.6
sl5 | 4|brown | 1|m | 100
sl6 | 0|brown | 0.9|m | 90
(8 rows)
</ProgramListing>
move the arrived shoelaces in
<ProgramListing>
al_bundy=> INSERT INTO shoelace_ok SELECT * FROM shoelace_arrive;
al_bundy=> INSERT INTO shoelace_ok SELECT * FROM shoelace_arrive;
</ProgramListing>
and check the results
<ProgramListing>
al_bundy=> SELECT * FROM shoelace ORDER BY sl_name;
sl_name |sl_avail|sl_color |sl_len|sl_unit |sl_len_cm
----------+--------+----------+------+--------+---------
sl1 | 5|black | 80|cm | 80
sl2 | 6|black | 100|cm | 100
sl7 | 6|brown | 60|cm | 60
sl4 | 8|black | 40|inch | 101.6
sl3 | 10|black | 35|inch | 88.9
sl8 | 21|brown | 40|inch | 101.6
sl5 | 4|brown | 1|m | 100
sl6 | 20|brown | 0.9|m | 90
(8 rows)
al_bundy=> SELECT * FROM shoelace_log;
sl_name |sl_avail|log_who|log_when
----------+--------+-------+--------------------------------
sl7 | 6|Al |Tue Oct 20 19:14:45 1998 MET DST
sl3 | 10|Al |Tue Oct 20 19:25:16 1998 MET DST
sl6 | 20|Al |Tue Oct 20 19:25:16 1998 MET DST
sl8 | 21|Al |Tue Oct 20 19:25:16 1998 MET DST
(4 rows)
al_bundy=> SELECT * FROM shoelace ORDER BY sl_name;
sl_name |sl_avail|sl_color |sl_len|sl_unit |sl_len_cm
----------+--------+----------+------+--------+---------
sl1 | 5|black | 80|cm | 80
sl2 | 6|black | 100|cm | 100
sl7 | 6|brown | 60|cm | 60
sl4 | 8|black | 40|inch | 101.6
sl3 | 10|black | 35|inch | 88.9
sl8 | 21|brown | 40|inch | 101.6
sl5 | 4|brown | 1|m | 100
sl6 | 20|brown | 0.9|m | 90
(8 rows)
al_bundy=> SELECT * FROM shoelace_log;
sl_name |sl_avail|log_who|log_when
----------+--------+-------+--------------------------------
sl7 | 6|Al |Tue Oct 20 19:14:45 1998 MET DST
sl3 | 10|Al |Tue Oct 20 19:25:16 1998 MET DST
sl6 | 20|Al |Tue Oct 20 19:25:16 1998 MET DST
sl8 | 21|Al |Tue Oct 20 19:25:16 1998 MET DST
(4 rows)
</ProgramListing>
It's a long way from the one INSERT ... SELECT to these
......@@ -1455,21 +1455,21 @@
document (but not the last example :-). First there was the parser's output
<ProgramListing>
INSERT INTO shoelace_ok SELECT
shoelace_arrive.arr_name, shoelace_arrive.arr_quant
FROM shoelace_arrive shoelace_arrive, shoelace_ok shoelace_ok;
INSERT INTO shoelace_ok SELECT
shoelace_arrive.arr_name, shoelace_arrive.arr_quant
FROM shoelace_arrive shoelace_arrive, shoelace_ok shoelace_ok;
</ProgramListing>
Now the first rule <literal>shoelace_ok_ins</literal> is applied and turns it
into
<ProgramListing>
UPDATE shoelace SET
sl_avail = int4pl(shoelace.sl_avail, shoelace_arrive.arr_quant)
FROM shoelace_arrive shoelace_arrive, shoelace_ok shoelace_ok,
shoelace_ok *OLD*, shoelace_ok *NEW*,
shoelace shoelace
WHERE bpchareq(shoelace.sl_name, showlace_arrive.arr_name);
UPDATE shoelace SET
sl_avail = int4pl(shoelace.sl_avail, shoelace_arrive.arr_quant)
FROM shoelace_arrive shoelace_arrive, shoelace_ok shoelace_ok,
shoelace_ok *OLD*, shoelace_ok *NEW*,
shoelace shoelace
WHERE bpchareq(shoelace.sl_name, showlace_arrive.arr_name);
</ProgramListing>
and throws away the original INSERT on <Filename>shoelace_ok</Filename>.
......@@ -1477,18 +1477,18 @@
the second applied rule <literal>shoelace_upd</literal> produced
<ProgramListing>
UPDATE shoelace_data SET
sl_name = shoelace.sl_name,
sl_avail = int4pl(shoelace.sl_avail, shoelace_arrive.arr_quant),
sl_color = shoelace.sl_color,
sl_len = shoelace.sl_len,
sl_unit = shoelace.sl_unit
FROM shoelace_arrive shoelace_arrive, shoelace_ok shoelace_ok,
shoelace_ok *OLD*, shoelace_ok *NEW*,
shoelace shoelace, shoelace *OLD*,
shoelace *NEW*, shoelace_data showlace_data
WHERE bpchareq(shoelace.sl_name, showlace_arrive.arr_name)
AND bpchareq(shoelace_data.sl_name, shoelace.sl_name);
UPDATE shoelace_data SET
sl_name = shoelace.sl_name,
sl_avail = int4pl(shoelace.sl_avail, shoelace_arrive.arr_quant),
sl_color = shoelace.sl_color,
sl_len = shoelace.sl_len,
sl_unit = shoelace.sl_unit
FROM shoelace_arrive shoelace_arrive, shoelace_ok shoelace_ok,
shoelace_ok *OLD*, shoelace_ok *NEW*,
shoelace shoelace, shoelace *OLD*,
shoelace *NEW*, shoelace_data showlace_data
WHERE bpchareq(shoelace.sl_name, showlace_arrive.arr_name)
AND bpchareq(shoelace_data.sl_name, shoelace.sl_name);
</ProgramListing>
Again it's an INSTEAD rule and the previous parse tree is trashed.
......@@ -1497,20 +1497,20 @@
and applies the rule <literal>_RETshoelace</literal> on it and we get
<ProgramListing>
UPDATE shoelace_data SET
sl_name = s.sl_name,
sl_avail = int4pl(s.sl_avail, shoelace_arrive.arr_quant),
sl_color = s.sl_color,
sl_len = s.sl_len,
sl_unit = s.sl_unit
FROM shoelace_arrive shoelace_arrive, shoelace_ok shoelace_ok,
shoelace_ok *OLD*, shoelace_ok *NEW*,
shoelace shoelace, shoelace *OLD*,
shoelace *NEW*, shoelace_data showlace_data,
shoelace *OLD*, shoelace *NEW*,
shoelace_data s, unit u
WHERE bpchareq(s.sl_name, showlace_arrive.arr_name)
AND bpchareq(shoelace_data.sl_name, s.sl_name);
UPDATE shoelace_data SET
sl_name = s.sl_name,
sl_avail = int4pl(s.sl_avail, shoelace_arrive.arr_quant),
sl_color = s.sl_color,
sl_len = s.sl_len,
sl_unit = s.sl_unit
FROM shoelace_arrive shoelace_arrive, shoelace_ok shoelace_ok,
shoelace_ok *OLD*, shoelace_ok *NEW*,
shoelace shoelace, shoelace *OLD*,
shoelace *NEW*, shoelace_data showlace_data,
shoelace *OLD*, shoelace *NEW*,
shoelace_data s, unit u
WHERE bpchareq(s.sl_name, showlace_arrive.arr_name)
AND bpchareq(shoelace_data.sl_name, s.sl_name);
</ProgramListing>
Again an update rule has been applied and so the wheel
......@@ -1519,23 +1519,22 @@
parse tree
<ProgramListing>
INSERT INTO shoelace_log SELECT
s.sl_name,
int4pl(s.sl_avail, shoelace_arrive.arr_quant),
current_user,
current_timestamp
FROM shoelace_arrive shoelace_arrive, shoelace_ok shoelace_ok,
shoelace_ok *OLD*, shoelace_ok *NEW*,
shoelace shoelace, shoelace *OLD*,
shoelace *NEW*, shoelace_data showlace_data,
shoelace *OLD*, shoelace *NEW*,
shoelace_data s, unit u,
shoelace_data *OLD*, shoelace_data *NEW*
shoelace_log shoelace_log
WHERE bpchareq(s.sl_name, showlace_arrive.arr_name)
AND bpchareq(shoelace_data.sl_name, s.sl_name);
AND int4ne(int4pl(s.sl_avail, shoelace_arrive.arr_quant),
s.sl_avail);
INSERT INTO shoelace_log SELECT
s.sl_name,
int4pl(s.sl_avail, shoelace_arrive.arr_quant),
current_user,
current_timestamp
FROM shoelace_arrive shoelace_arrive, shoelace_ok shoelace_ok,
shoelace_ok *OLD*, shoelace_ok *NEW*,
shoelace shoelace, shoelace *OLD*,
shoelace *NEW*, shoelace_data showlace_data,
shoelace *OLD*, shoelace *NEW*,
shoelace_data s, unit u,
shoelace_data *OLD*, shoelace_data *NEW*
shoelace_log shoelace_log
WHERE bpchareq(s.sl_name, showlace_arrive.arr_name)
AND bpchareq(shoelace_data.sl_name, s.sl_name);
AND int4ne(int4pl(s.sl_avail, shoelace_arrive.arr_quant), s.sl_avail);
</ProgramListing>
After that the rule system runs out of rules and returns the
......@@ -1544,24 +1543,24 @@
<Acronym>SQL</Acronym> statements
<ProgramListing>
INSERT INTO shoelace_log SELECT
s.sl_name,
s.sl_avail + shoelace_arrive.arr_quant,
current_user,
current_timestamp
FROM shoelace_arrive shoelace_arrive, shoelace_data shoelace_data,
shoelace_data s
WHERE s.sl_name = shoelace_arrive.arr_name
AND shoelace_data.sl_name = s.sl_name
AND s.sl_avail + shoelace_arrive.arr_quant != s.sl_avail;
INSERT INTO shoelace_log SELECT
s.sl_name,
s.sl_avail + shoelace_arrive.arr_quant,
current_user,
current_timestamp
FROM shoelace_arrive shoelace_arrive, shoelace_data shoelace_data,
shoelace_data s
WHERE s.sl_name = shoelace_arrive.arr_name
AND shoelace_data.sl_name = s.sl_name
AND s.sl_avail + shoelace_arrive.arr_quant != s.sl_avail;
UPDATE shoelace_data SET
sl_avail = shoelace_data.sl_avail + shoelace_arrive.arr_quant
FROM shoelace_arrive shoelace_arrive,
shoelace_data shoelace_data,
shoelace_data s
WHERE s.sl_name = shoelace_arrive.sl_name
AND shoelace_data.sl_name = s.sl_name;
UPDATE shoelace_data SET
sl_avail = shoelace_data.sl_avail + shoelace_arrive.arr_quant
FROM shoelace_arrive shoelace_arrive,
shoelace_data shoelace_data,
shoelace_data s
WHERE s.sl_name = shoelace_arrive.sl_name
AND shoelace_data.sl_name = s.sl_name;
</ProgramListing>
The result is that data coming from one relation inserted into another,
......@@ -1621,10 +1620,10 @@ Merge Join
his database for pink ones.
<ProgramListing>
al_bundy=> INSERT INTO shoelace VALUES
al_bundy-> ('sl9', 0, 'pink', 35.0, 'inch', 0.0);
al_bundy=> INSERT INTO shoelace VALUES
al_bundy-> ('sl10', 1000, 'magenta', 40.0, 'inch', 0.0);
al_bundy=> INSERT INTO shoelace VALUES
al_bundy-> ('sl9', 0, 'pink', 35.0, 'inch', 0.0);
al_bundy=> INSERT INTO shoelace VALUES
al_bundy-> ('sl10', 1000, 'magenta', 40.0, 'inch', 0.0);
</ProgramListing>
Since this happens often, we must lookup for shoelace entries,
......@@ -1633,19 +1632,19 @@ Merge Join
for it. The view for this is
<ProgramListing>
CREATE VIEW shoelace_obsolete AS
SELECT * FROM shoelace WHERE NOT EXISTS
(SELECT shoename FROM shoe WHERE slcolor = sl_color);
CREATE VIEW shoelace_obsolete AS
SELECT * FROM shoelace WHERE NOT EXISTS
(SELECT shoename FROM shoe WHERE slcolor = sl_color);
</ProgramListing>
Its output is
<ProgramListing>
al_bundy=> SELECT * FROM shoelace_obsolete;
sl_name |sl_avail|sl_color |sl_len|sl_unit |sl_len_cm
----------+--------+----------+------+--------+---------
sl9 | 0|pink | 35|inch | 88.9
sl10 | 1000|magenta | 40|inch | 101.6
al_bundy=> SELECT * FROM shoelace_obsolete;
sl_name |sl_avail|sl_color |sl_len|sl_unit |sl_len_cm
----------+--------+----------+------+--------+---------
sl9 | 0|pink | 35|inch | 88.9
sl10 | 1000|magenta | 40|inch | 101.6
</ProgramListing>
For the 1000 magenta shoelaces we must debt Al before we can
......@@ -1654,34 +1653,34 @@ Merge Join
we don't delete it directly. Instead we create one more view
<ProgramListing>
CREATE VIEW shoelace_candelete AS
SELECT * FROM shoelace_obsolete WHERE sl_avail = 0;
CREATE VIEW shoelace_candelete AS
SELECT * FROM shoelace_obsolete WHERE sl_avail = 0;
</ProgramListing>
and do it this way:
<ProgramListing>
DELETE FROM shoelace WHERE EXISTS
(SELECT * FROM shoelace_candelete
WHERE sl_name = shoelace.sl_name);
DELETE FROM shoelace WHERE EXISTS
(SELECT * FROM shoelace_candelete
WHERE sl_name = shoelace.sl_name);
</ProgramListing>
Voilà:
<foreignphrase>Voilà</foreignphrase>:
<ProgramListing>
al_bundy=> SELECT * FROM shoelace;
sl_name |sl_avail|sl_color |sl_len|sl_unit |sl_len_cm
----------+--------+----------+------+--------+---------
sl1 | 5|black | 80|cm | 80
sl2 | 6|black | 100|cm | 100
sl7 | 6|brown | 60|cm | 60
sl4 | 8|black | 40|inch | 101.6
sl3 | 10|black | 35|inch | 88.9
sl8 | 21|brown | 40|inch | 101.6
sl10 | 1000|magenta | 40|inch | 101.6
sl5 | 4|brown | 1|m | 100
sl6 | 20|brown | 0.9|m | 90
(9 rows)
al_bundy=> SELECT * FROM shoelace;
sl_name |sl_avail|sl_color |sl_len|sl_unit |sl_len_cm
----------+--------+----------+------+--------+---------
sl1 | 5|black | 80|cm | 80
sl2 | 6|black | 100|cm | 100
sl7 | 6|brown | 60|cm | 60
sl4 | 8|black | 40|inch | 101.6
sl3 | 10|black | 35|inch | 88.9
sl8 | 21|brown | 40|inch | 101.6
sl10 | 1000|magenta | 40|inch | 101.6
sl5 | 4|brown | 1|m | 100
sl6 | 20|brown | 0.9|m | 90
(9 rows)
</ProgramListing>
A DELETE on a view, with a subselect qualification that
......@@ -1738,10 +1737,10 @@ Merge Join
He can construct the following:
<ProgramListing>
CREATE TABLE phone_data (person text, phone text, private bool);
CREATE VIEW phone_number AS
SELECT person, phone FROM phone_data WHERE NOT private;
GRANT SELECT ON phone_number TO secretary;
CREATE TABLE phone_data (person text, phone text, private bool);
CREATE VIEW phone_number AS
SELECT person, phone FROM phone_data WHERE NOT private;
GRANT SELECT ON phone_number TO secretary;
</ProgramListing>
Nobody except him (and the database superusers) can access the
......@@ -1840,15 +1839,15 @@ Merge Join
For example: There are two tables
<ProgramListing>
CREATE TABLE computer (
hostname text, -- indexed
manufacturer text -- indexed
);
CREATE TABLE computer (
hostname text, -- indexed
manufacturer text -- indexed
);
CREATE TABLE software (
software text, -- indexed
hostname text -- indexed
);
CREATE TABLE software (
software text, -- indexed
hostname text -- indexed
);
</ProgramListing>
Both tables have many
......@@ -1860,21 +1859,21 @@ Merge Join
deleted from computer, it can use the statement
<ProgramListing>
DELETE FROM software WHERE hostname = $1;
DELETE FROM software WHERE hostname = $1;
</ProgramListing>
in a prepared and saved plan and pass the <structfield>hostname</> in
the parameter. The rule would be written as
<ProgramListing>
CREATE RULE computer_del AS ON DELETE TO computer
DO DELETE FROM software WHERE hostname = OLD.hostname;
CREATE RULE computer_del AS ON DELETE TO computer
DO DELETE FROM software WHERE hostname = OLD.hostname;
</ProgramListing>
Now we look at different types of deletes. In the case of a
<ProgramListing>
DELETE FROM computer WHERE hostname = 'mypc.local.net';
DELETE FROM computer WHERE hostname = 'mypc.local.net';
</ProgramListing>
the table computer is scanned by index (fast) and the
......@@ -1882,17 +1881,17 @@ Merge Join
The extra query from the rule would be a
<ProgramListing>
DELETE FROM software WHERE computer.hostname = 'mypc.local.net'
AND software.hostname = computer.hostname;
DELETE FROM software WHERE computer.hostname = 'mypc.local.net'
AND software.hostname = computer.hostname;
</ProgramListing>
Since there are appropriate indexes setup, the planner
will create a plan of
<ProgramListing>
Nestloop
-> Index Scan using comp_hostidx on computer
-> Index Scan using soft_hostidx on software
Nestloop
-> Index Scan using comp_hostidx on computer
-> Index Scan using soft_hostidx on software
</ProgramListing>
So there would be not that much difference in speed between
......@@ -1901,31 +1900,31 @@ Merge Join
with 'old'. There are two possible queries to do that. One is
<ProgramListing>
DELETE FROM computer WHERE hostname >= 'old'
AND hostname < 'ole'
DELETE FROM computer WHERE hostname >= 'old'
AND hostname < 'ole'
</ProgramListing>
Where the plan for the rule query will be a
<ProgramListing>
Hash Join
-> Seq Scan on software
-> Hash
-> Index Scan using comp_hostidx on computer
Hash Join
-> Seq Scan on software
-> Hash
-> Index Scan using comp_hostidx on computer
</ProgramListing>
The other possible query is a
<ProgramListing>
DELETE FROM computer WHERE hostname ~ '^old';
DELETE FROM computer WHERE hostname ~ '^old';
</ProgramListing>
with the execution plan
<ProgramListing>
Nestloop
-> Index Scan using comp_hostidx on computer
-> Index Scan using soft_hostidx on software
Nestloop
-> Index Scan using comp_hostidx on computer
-> Index Scan using soft_hostidx on software
</ProgramListing>
This shows, that the planner does not realize that the
......@@ -1948,7 +1947,7 @@ Merge Join
The last query we look at is a
<ProgramListing>
DELETE FROM computer WHERE manufacurer = 'bim';
DELETE FROM computer WHERE manufacurer = 'bim';
</ProgramListing>
Again this could result in many rows to be deleted from
......@@ -1957,16 +1956,16 @@ Merge Join
two index scans. Only using another index on computer:
<ProgramListing>
Nestloop
-> Index Scan using comp_manufidx on computer
-> Index Scan using soft_hostidx on software
Nestloop
-> Index Scan using comp_manufidx on computer
-> Index Scan using soft_hostidx on software
</ProgramListing>
resulting from the rules query
<ProgramListing>
DELETE FROM software WHERE computer.manufacurer = 'bim'
AND software.hostname = computer.hostname;
DELETE FROM software WHERE computer.manufacurer = 'bim'
AND software.hostname = computer.hostname;
</ProgramListing>
In any of these cases, the extra queries from the rule system will be
......
doc/src/sgml/runtime.sgml
View file @ bf43bed8
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/runtime.sgml,v 1.102 2002/01/09 00:52:38 petere Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/runtime.sgml,v 1.103 2002/01/20 22:19:56 petere Exp $
-->
<Chapter Id="runtime">
......@@ -187,7 +187,7 @@ $ <userinput>postmaster -D /usr/local/pgsql/data</userinput>
<screen>
$ <userinput>postmaster -D /usr/local/pgsql/data &gt; logfile 2&gt;&amp;1 &amp;</userinput>
</screen>
It is an extremely good idea to keep the server's stdout and stderr
It is an extremely good idea to keep the server's <systemitem>stdout</> and <systemitem>stderr</>
output around somewhere, as suggested here. It will help both for auditing
purposes and to diagnose problems.
(See <xref linkend="logfile-maintenance"> for a more thorough discussion
......@@ -1208,9 +1208,9 @@ dynamic_library_path = '/usr/local/lib/postgresql:/home/my_project/lib:$libdir'
<para>
It should be noted that the performance penalty from doing
fsyncs is considerably less in <productname>PostgreSQL</> version
<function>fsync</>s is considerably less in <productname>PostgreSQL</> version
7.1 than it was in prior releases. If you previously suppressed
fsyncs because of performance problems, you may wish to reconsider
<function>fsync</>s because of performance problems, you may wish to reconsider
your choice.
</para>
......@@ -1263,9 +1263,9 @@ dynamic_library_path = '/usr/local/lib/postgresql:/home/my_project/lib:$libdir'
subprocess. The default is 1000. The limit actually used by the code
is the smaller of this setting and the result of
<literal>sysconf(_SC_OPEN_MAX)</literal>.
Therefore, on systems where sysconf returns a reasonable limit,
Therefore, on systems where <function>sysconf</> returns a reasonable limit,
you don't need to worry about this setting. But on some platforms
(notably, most BSD systems), sysconf returns a value that is much
(notably, most BSD systems), <function>sysconf</> returns a value that is much
larger than the system can really support when a large number of
processes all try to open that many files. If you find yourself
seeing <quote>Too many open files</> failures, try reducing this
......@@ -1599,7 +1599,7 @@ dynamic_library_path = '/usr/local/lib/postgresql:/home/my_project/lib:$libdir'
<para>
Time delay between writing a commit record to the WAL buffer and
flushing the buffer out to disk, in microseconds. A nonzero delay
allows multiple transactions to be committed with only one fsync,
allows multiple transactions to be committed with only one <function>fsync</function> system call,
if system load is high enough that additional transactions become
ready to commit within the given interval. But the delay is just
wasted time if no other transactions become ready to commit.
......@@ -1659,10 +1659,10 @@ dynamic_library_path = '/usr/local/lib/postgresql:/home/my_project/lib:$libdir'
<para>
Method used for forcing WAL updates out to disk. Possible
values are
<literal>FSYNC</> (call fsync() at each commit),
<literal>FDATASYNC</> (call fdatasync() at each commit),
<literal>OPEN_SYNC</> (write WAL files with open() option O_SYNC), or
<literal>OPEN_DATASYNC</> (write WAL files with open() option O_DSYNC).
<literal>FSYNC</> (call <function>fsync()</> at each commit),
<literal>FDATASYNC</> (call <function>fdatasync()</> at each commit),
<literal>OPEN_SYNC</> (write WAL files with <function>open()</> option <symbol>O_SYNC</>), or
<literal>OPEN_DATASYNC</> (write WAL files with <function>open()</> option <symbol>O_DSYNC</>).
Not all of these choices are available on all platforms.
This option can only be set at server start or in the
<filename>postgresql.conf</filename> file.
......
doc/src/sgml/sources.sgml
View file @ bf43bed8
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/sources.sgml,v 2.5 2001/11/21 06:09:45 thomas Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/sources.sgml,v 2.6 2002/01/20 22:19:56 petere Exp $
-->
<chapter id="source">
......@@ -14,7 +14,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/sources.sgml,v 2.5 2001/11/21 06:09:45 thom
</para>
<para>
For emacs, add the following (or something similar)
For Emacs, add the following (or something similar)
to your <filename>~/.emacs</filename>
initialization file:
......
doc/src/sgml/start.sgml
View file @ bf43bed8
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/start.sgml,v 1.21 2001/11/28 20:49:10 petere Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/start.sgml,v 1.22 2002/01/20 22:19:56 petere Exp $
-->
<chapter id="tutorial-start">
......@@ -152,7 +152,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/start.sgml,v 1.21 2001/11/28 20:49:10 peter
<para>
To create a new database, in this example named
<quote>mydb</quote>, you use the following command:
<literal>mydb</literal>, you use the following command:
<screen>
<prompt>$</prompt> <userinput>createdb mydb</userinput>
</screen>
......@@ -244,7 +244,7 @@ createdb: database creation failed
<para>
If you don't want to use your database anymore you can remove it.
For example, if you are the owner (creator) of the database
<quote>mydb</quote>, you can destroy it using the following
<literal>mydb</literal>, you can destroy it using the following
command:
<screen>
<prompt>$</prompt> <userinput>dropdb mydb</userinput>
......@@ -272,7 +272,7 @@ createdb: database creation failed
<listitem>
<para>
Running the <productname>PostgreSQL</productname> interactive
terminal program, called <quote>psql</quote>, which allows you
terminal program, called <application><firstterm>psql</></application>, which allows you
to interactively enter, edit, and execute
<acronym>SQL</acronym> commands.
</para>
......@@ -300,7 +300,7 @@ createdb: database creation failed
You probably want to start up <command>psql</command>, to try out
the examples in this tutorial. It can be activated for the
<quote>mydb</quote> database by typing the command:
<literal>mydb</literal> database by typing the command:
<screen>
<prompt>$</prompt> <userinput>psql mydb</userinput>
</screen>
......@@ -346,7 +346,7 @@ mydb=#
The last line printed out by <command>psql</command> is the
prompt, and it indicates that <command>psql</command> is listening
to you and that you can type <acronym>SQL</acronym> queries into a
workspace maintained by <command>psql</command>. Try out these
work space maintained by <command>psql</command>. Try out these
commands:
<indexterm><primary>version</primary></indexterm>
<screen>
......
doc/src/sgml/syntax.sgml
View file @ bf43bed8
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/syntax.sgml,v 1.57 2002/01/09 23:38:06 tgl Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/syntax.sgml,v 1.58 2002/01/20 22:19:56 petere Exp $
-->
<chapter id="sql-syntax">
......@@ -1019,7 +1019,7 @@ sqrt(2)
</indexterm>
<para>
A type cast specifies a conversion from one datatype to another.
A type cast specifies a conversion from one data type to another.
<productname>PostgreSQL</productname> accepts two equivalent syntaxes
for type casts:
<synopsis>
......@@ -1039,8 +1039,8 @@ CAST ( <replaceable>expression</replaceable> AS <replaceable>type</replaceable>
<xref linkend="sql-syntax-constants-generic">. A cast applied to an
unadorned string literal represents the initial assignment of a type
to a literal constant value, and so it will succeed for any type
(if the string literal's contents are acceptable input syntax for the
datatype).
(if the contents of the string literal are acceptable input syntax for the
data type).
</para>
<para>
......
doc/src/sgml/typeconv.sgml
View file @ bf43bed8
......@@ -43,7 +43,7 @@ has an associated data type which determines its behavior and allowed usage.
<productname>PostgreSQL</productname> has an extensible type system that is
much more general and flexible than other <acronym>RDBMS</acronym> implementations.
Hence, most type conversion behavior in <productname>PostgreSQL</productname>
should be governed by general rules rather than by 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.
</para>
......@@ -178,7 +178,7 @@ Implicit conversions should never have surprising or unpredictable outcomes.
<listitem>
<para>
User-defined types, of which the parser has no a-priori knowledge, should be
User-defined types, of which the parser has no <foreignphrase>a priori</> knowledge, should be
<quote>higher</quote> in the type hierarchy. In mixed-type expressions, native types shall always
be converted to a user-defined type (of course, only if conversion is necessary).
</para>
......@@ -410,7 +410,7 @@ type to resolve the unknown literals to.
<para>
The <productname>PostgreSQL</productname> operator catalog has several
entries for the prefix operator <literal>@</>, all of which implement
absolute-value operations for various numeric datatypes. One of these
absolute-value operations for various numeric data types. One of these
entries is for type <type>float8</type>, which is the preferred type in
the numeric category. Therefore, <productname>PostgreSQL</productname>
will use that entry when faced with a non-numeric input:
......@@ -432,7 +432,7 @@ ERROR: Input '-4.5e500' is out of range for float8
<para>
On the other hand, the postfix operator <literal>!</> (factorial)
is defined only for integer datatypes, not for float8. So, if we
is defined only for integer data types, not for float8. So, if we
try a similar case with <literal>!</>, we get:
<screen>
tgl=> select text '44' ! as "factorial";
......@@ -657,7 +657,7 @@ system catalog.
<para>
Values to be inserted into a table are coerced to the destination
column's datatype according to the
column's data type according to the
following steps.
</para>
......@@ -712,7 +712,7 @@ What has really happened here is that the two unknown literals are resolved
to <type>text</type> by default, allowing the <literal>||</literal> operator
to be resolved as <type>text</type> concatenation. Then the <type>text</type>
result of the operator is coerced to <type>bpchar</type> (<quote>blank-padded
char</>, the internal name of the character datatype) to match the target
char</>, the internal name of the character data type) to match the target
column type. (Since the parser knows that <type>text</type> and
<type>bpchar</type> are binary-compatible, this coercion is implicit and does
not insert any real function call.) Finally, the sizing function
......@@ -734,7 +734,7 @@ to each output column of a union query. The <literal>INTERSECT</> and
<literal>EXCEPT</> constructs resolve dissimilar types in the same way as
<literal>UNION</>.
A <literal>CASE</> construct also uses the identical algorithm to match up its
component expressions and select a result datatype.
component expressions and select a result data type.
</para>
<procedure>
<title><literal>UNION</> and <literal>CASE</> Type Resolution</title>
......
doc/src/sgml/xfunc.sgml
View file @ bf43bed8
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/xfunc.sgml,v 1.46 2002/01/07 02:29:14 petere Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/xfunc.sgml,v 1.47 2002/01/20 22:19:56 petere Exp $
-->
<chapter id="xfunc">
......@@ -215,7 +215,7 @@ SELECT one();
<para>
Notice that we defined a column alias within the function body for the result of the function
(with the name <literal>RESULT</>), but this column alias is not visible
outside the function. Hence, the result is labelled <literal>one</>
outside the function. Hence, the result is labeled <literal>one</>
instead of <literal>RESULT</>.
</para>
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment