Corrections to manuals [patch]

I attach a patch containing corrections to the Tutorial and User's Guide for
spelling, grammar, euphony and (occasionally) content. I've got as far as
ALTER TABLE in chapter 14 of the User's Guide. I'll get on to the others sometime.

Please note that <quote>...</quote> produces only surrounding spaces in the
Postscript versions as printed by a HP Laserjet 6MP and by ghostscript.
I have not attempted to change these.

Tom, is it possible to make the printed text fully justified? It would
look a lot better, I think.

======================== patch against 6.5 ==============================
diff -cr doc/src/sgml.orig/datatype.sgml doc/src/sgml/datatype.sgml
*** doc/src/sgml.orig/datatype.sgml Mon Jul 19 10:39:07 1999
--- doc/src/sgml/datatype.sgml Mon Jul 19 10:49:04 1999
***************
*** 478,484 ****
special type to use for internal names.
It is not intended for use by the general user.
It's length is currently defined as 32 chars
! but should be reference using NAMEDATALEN.
This is set at compile time and may change in a future release.
</para>

--- 478,484 ----
special type to use for internal names.
It is not intended for use by the general user.
It's length is currently defined as 32 chars
! but should be referenced using NAMEDATALEN.
This is set at compile time and may change in a future release.
</para>

***************
*** 580,585 ****
--- 580,591 ----
<entry>limited range, low precision</entry>
</row>
<row>
+ <entry>tinterval</entry>
+ <entry>4 bytes</entry>
+ <entry>use only with abstimes</entry>
+ <entry>limited range, low precision</entry>
+ </row>
+ <row>
<entry>time</entry>
<entry>4 bytes</entry>
<entry><acronym>SQL92</acronym> type</entry>
***************
*** 775,781 ****

<para>
The <acronym>SQL</acronym> style has European and non-European (US) variants,
! which determines whether month follows day or vica versa.

<table tocentry="1">
<title><productname>Postgres</productname> Date Order Conventions</title>
--- 781,787 ----

<para>
The <acronym>SQL</acronym> style has European and non-European (US) variants,
! which determines whether month follows day or vice versa.

<table tocentry="1">
<title><productname>Postgres</productname> Date Order Conventions</title>
***************
*** 856,862 ****

<para>
Date conventions before the 19th century make for interesting reading,
! but are not consistant enough to warrant coding into a date/time handler.
</para>
</sect2>

--- 862,869 ----

<para>
Date conventions before the 19th century make for interesting reading,
! but are not consistent enough to warrant coding into a date/time handler.
! <comment>so what happens?</comment>
</para>
</sect2>

***************
*** 1032,1052 ****
</row>
<row>
<entry>1/8/1999</entry>
! <entry>US; read as August 1 in European mode</entry>
</row>
<row>
<entry>8/1/1999</entry>
! <entry>European; read as August 1 in US mode</entry>
</row>
<row>
<entry>1/18/1999</entry>
<entry>US; read as January 18 in any mode</entry>
</row>
<row>
- <entry>1999.008</entry>
- <entry>Year and day of year</entry>
- </row>
- <row>
<entry>19990108</entry>
<entry>ISO-8601 year, month, day</entry>
</row>
--- 1039,1055 ----
</row>
<row>
<entry>1/8/1999</entry>
! <entry>US (NB: read as August 1 in European mode)</entry>
</row>
<row>
<entry>8/1/1999</entry>
! <entry>European (NB: read as August 1 in US mode)</entry>
</row>
<row>
<entry>1/18/1999</entry>
<entry>US; read as January 18 in any mode</entry>
</row>
<row>
<entry>19990108</entry>
<entry>ISO-8601 year, month, day</entry>
</row>
***************
*** 1084,1131 ****
</thead>
<tbody>
<row>
! <entry>April</entry>
! <entry>Apr</entry>
! </row>
! <row>
! <entry>August</entry>
! <entry>Aug</entry>
! </row>
! <row>
! <entry>December</entry>
! <entry>Dec</entry>
</row>
<row>
<entry>February</entry>
<entry>Feb</entry>
</row>
<row>
! <entry>January</entry>
! <entry>Jan</entry>
</row>
<row>
! <entry>July</entry>
! <entry>Jul</entry>
</row>
<row>
<entry>June</entry>
<entry>Jun</entry>
</row>
<row>
! <entry>March</entry>
! <entry>Mar</entry>
</row>
<row>
! <entry>November</entry>
! <entry>Nov</entry>
</row>
<row>
<entry>October</entry>
<entry>Oct</entry>
</row>
<row>
! <entry>September</entry>
! <entry>Sep, Sept</entry>
</row>
</tbody>
</tgroup>
--- 1087,1134 ----
</thead>
<tbody>
<row>
! <entry>January</entry>
! <entry>Jan</entry>
</row>
<row>
<entry>February</entry>
<entry>Feb</entry>
</row>
<row>
! <entry>March</entry>
! <entry>Mar</entry>
</row>
<row>
! <entry>April</entry>
! <entry>Apr</entry>
</row>
<row>
<entry>June</entry>
<entry>Jun</entry>
</row>
<row>
! <entry>July</entry>
! <entry>Jul</entry>
</row>
<row>
! <entry>August</entry>
! <entry>Aug</entry>
! </row>
! <row>
! <entry>September</entry>
! <entry>Sep, Sept</entry>
</row>
<row>
<entry>October</entry>
<entry>Oct</entry>
</row>
<row>
! <entry>November</entry>
! <entry>Nov</entry>
! </row>
! <row>
! <entry>December</entry>
! <entry>Dec</entry>
</row>
</tbody>
</tgroup>
***************
*** 1761,1767 ****
--- 1764,1772 ----
( ( x , y ) , r )
( x , y ) , r
x , y , r
+ </programlisting>
where
+ <programlisting>
(x,y) is the center of the circle
r is the radius of the circle
</programlisting>
diff -cr doc/src/sgml.orig/environ.sgml doc/src/sgml/environ.sgml
*** doc/src/sgml.orig/environ.sgml Mon Jul 19 11:16:14 1999
--- doc/src/sgml/environ.sgml Mon Jul 19 11:23:19 1999
***************
*** 32,46 ****
a variant of the Bourne shell, such as <Application>sh</Application>, <Application>ksh</Application>, or
<Application>bash</Application>, then you would add
<ProgramListing>
! $ PATH=/usr/local/pgsql/bin:$PATH
! $ export PATH
</ProgramListing>
to the <FileName>.profile</FileName> file in your home directory.
From now on, we will assume that you have added the
! <ProductName>Postgres</ProductName> bin directory to your path. In addition, we
will make frequent reference to <Quote>setting a shell
! variable</Quote> or <Quote>setting an environment variable</Quote> throughout
! this document. If you did not fully understand the
last paragraph on modifying your search path, you
should consult the UNIX manual pages that describe your
shell before going any further.
--- 32,47 ----
a variant of the Bourne shell, such as <Application>sh</Application>, <Application>ksh</Application>, or
<Application>bash</Application>, then you would add
<ProgramListing>
! PATH=/usr/local/pgsql/bin:$PATH
! export PATH
</ProgramListing>
to the <FileName>.profile</FileName> file in your home directory.
From now on, we will assume that you have added the
! <ProductName>Postgres</ProductName> bin directory to your path.
! In addition, throughout this document, we
will make frequent reference to <Quote>setting a shell
! variable</Quote> or <Quote>setting an environment variable</Quote>.
! If you did not fully understand the
last paragraph on modifying your search path, you
should consult the UNIX manual pages that describe your
shell before going any further.
diff -cr doc/src/sgml.orig/info.sgml doc/src/sgml/info.sgml
*** doc/src/sgml.orig/info.sgml Mon Jul 19 10:12:55 1999
--- doc/src/sgml/info.sgml Mon Jul 19 10:14:44 1999
***************
*** 116,122 ****
<Term>Mailing Lists</Term>
<ListItem>
<Para>
! The <ULink url="mailto:questions(at)postgresql(dot)org"><ProductName>Postgres</ProductName> Questions</ULink>
mailing list is a good place to have user questions answered. Other mailing lists are available; consult
the web page for details.
</Para>
--- 116,122 ----
<Term>Mailing Lists</Term>
<ListItem>
<Para>
! The <ULink url="mailto:pgsql-general(at)postgresql(dot)org"><ProductName>Postgres</ProductName> General</ULink>
mailing list is a good place to have user questions answered. Other mailing lists are available; consult
the web page for details.
</Para>
diff -cr doc/src/sgml.orig/keys.sgml doc/src/sgml/keys.sgml
*** doc/src/sgml.orig/keys.sgml Mon Jul 19 11:02:52 1999
--- doc/src/sgml/keys.sgml Mon Jul 19 11:06:57 1999
***************
*** 62,86 ****
</ProgramListing>

<Para>
! A primary key is the field(s) used to identify a specific row. For example,
! Social Security numbers identifying a person.
</Para>
<Para>
! A simply UNIQUE combination of fields has nothing to do with identifying
! the row. It's simply an integrity constraint. For example, I have
! collections of links. Each collection is identified by a unique number,
which is the primary key. This key is used in relations.
</Para>
<Para>
! However, my application requires that each collection will also have a
unique name. Why? So that a human being who wants to modify a collection
! will be able to identify it. It's much harder to know, if you have two
! collections named "Life Science", the the one tagged 24433 is the one you
! need, and the one tagged 29882 is not.
</Para>
<Para>
So, the user selects the collection by its name. We therefore make sure,
! withing the database, that names are unique. However, no other table in the
database relates to the collections table by the collection Name. That
would be very inefficient.
</Para>
--- 62,86 ----
</ProgramListing>

<Para>
! A primary key is a field or combination of fields used to identify a specific row. For example,
! Social Security numbers identify a person.
</Para>
<Para>
! A simple UNIQUE combination of fields has nothing to do with identifying
! the row; it is simply an integrity constraint. For example, I may have
! collections of links, where each collection is identified by a unique number,
which is the primary key. This key is used in relations.
</Para>
<Para>
! However, my application requires that each collection should also have a
unique name. Why? So that a human being who wants to modify a collection
! will be able to identify it. It is hard to tell, if you have two
! collections named "Life Science", whether you need the one tagged 24433
! or the one tagged 29882.
</Para>
<Para>
So, the user selects the collection by its name. We therefore make sure,
! within the database, that names are unique. However, no other table in the
database relates to the collections table by the collection Name. That
would be very inefficient.
</Para>
***************
*** 161,167 ****
<programlisting>
CREATE MEMSTORE ON &lt;table&gt; COLUMNS &lt;cols&gt;
</programlisting>
! (this is not an existing command, just an example).
</Para>
<Para>
In fact, when you create a primary key or a unique combination of fields,
--- 161,167 ----
<programlisting>
CREATE MEMSTORE ON &lt;table&gt; COLUMNS &lt;cols&gt;
</programlisting>
! (this is not an actual command, just an example).
</Para>
<Para>
In fact, when you create a primary key or a unique combination of fields,
diff -cr doc/src/sgml.orig/manage.sgml doc/src/sgml/manage.sgml
*** doc/src/sgml.orig/manage.sgml Mon Jul 19 11:23:42 1999
--- doc/src/sgml/manage.sgml Mon Jul 19 11:26:10 1999
***************
*** 99,111 ****
<Note>
<Para>
In previous versions of <ProductName>Postgres</ProductName>,
! it was also permissable to use an absolute path name to specify
an alternate storage location.
Although the environment variable style of specification
is to be preferred since it allows the site administrator more flexibility in
! managing disk storage, it is also possible to use an absolute path
to specify an alternate location.
! The administrator's guide discusses how to enable this feature.
</Para>
</Note>

--- 99,111 ----
<Note>
<Para>
In previous versions of <ProductName>Postgres</ProductName>,
! it was also permissible to use an absolute path name to specify
an alternate storage location.
Although the environment variable style of specification
is to be preferred since it allows the site administrator more flexibility in
! managing disk storage, it is still possible to use an absolute path
to specify an alternate location.
! The administrator's guide explains how to enable this feature.
</Para>
</Note>

***************
*** 134,140 ****
To create a database in the alternate storage area <envar>PGDATA2</envar>
from the command line, use the following command:
<ProgramListing>
! % createdb -D PGDATA2 mydb
</ProgramListing>

and to do the same from within <Application>psql</Application> type
--- 134,140 ----
To create a database in the alternate storage area <envar>PGDATA2</envar>
from the command line, use the following command:
<ProgramListing>
! % createdb -D $PGDATA2 mydb
</ProgramListing>

and to do the same from within <Application>psql</Application> type
diff -cr doc/src/sgml.orig/mvcc.sgml doc/src/sgml/mvcc.sgml
*** doc/src/sgml.orig/mvcc.sgml Mon Jul 19 11:07:42 1999
--- doc/src/sgml/mvcc.sgml Mon Jul 19 11:14:53 1999
***************
*** 79,85 ****
<para>
A transaction re-executes a query returning a set of rows that satisfy a
search condition and finds that additional rows satisfying the condition
! has been inserted by another committed transaction.
</para>
</listitem>
</varlistentry>
--- 79,85 ----
<para>
A transaction re-executes a query returning a set of rows that satisfy a
search condition and finds that additional rows satisfying the condition
! have been inserted by another committed transaction.
</para>
</listitem>
</varlistentry>
***************
*** 90,96 ****
The four isolation levels and the corresponding behaviors are described below.

<table tocentry="1">
! <title><productname>Postgres</productname> Isolation Levels</title>
<titleabbrev>Isolation Levels</titleabbrev>
<tgroup cols="4">
<thead>
--- 90,96 ----
The four isolation levels and the corresponding behaviors are described below.

<table tocentry="1">
! <title>ANSI/ISO Isolation Levels</title>
<titleabbrev>Isolation Levels</titleabbrev>
<tgroup cols="4">
<thead>
***************
*** 192,198 ****
(or <command>DELETE</command>
or <command>SELECT FOR UPDATE</command>)
is being updated by a
! concurrent uncommitted transaction then the second transaction
that tries to update this row will wait for the other transaction to
commit or rollback. In the case of rollback, the waiting transaction
can proceed to change the row. In the case of commit (and if the
--- 192,198 ----
(or <command>DELETE</command>
or <command>SELECT FOR UPDATE</command>)
is being updated by a
! concurrent uncommitted transaction, the second transaction
that tries to update this row will wait for the other transaction to
commit or rollback. In the case of rollback, the waiting transaction
can proceed to change the row. In the case of commit (and if the
***************
*** 217,226 ****
<firstterm>Serializable</firstterm> provides the highest transaction isolation.
When a transaction is on the serializable level,
a query sees only data
! committed before the transaction began and never see either dirty data
or concurrent transaction changes committed during transaction
execution. So, this level emulates serial transaction execution,
! as if transactions would be executed one after another, serially,
rather than concurrently.
</para>

--- 217,226 ----
<firstterm>Serializable</firstterm> provides the highest transaction isolation.
When a transaction is on the serializable level,
a query sees only data
! committed before the transaction began and never sees either dirty data
or concurrent transaction changes committed during transaction
execution. So, this level emulates serial transaction execution,
! as if transactions were executed one after another, serially,
rather than concurrently.
</para>

***************
*** 229,235 ****
<command>UPDATE</command>
(or <command>DELETE</command> or <command>SELECT FOR UPDATE</command>)
statement is being updated by
! a concurrent uncommitted transaction then the second transaction
that tries to update this row will wait for the other transaction to
commit or rollback. In the case of rollback, the waiting transaction
can proceed to change the row. In the case of a concurrent
--- 229,235 ----
<command>UPDATE</command>
(or <command>DELETE</command> or <command>SELECT FOR UPDATE</command>)
statement is being updated by
! a concurrent uncommitted transaction, the second transaction
that tries to update this row will wait for the other transaction to
commit or rollback. In the case of rollback, the waiting transaction
can proceed to change the row. In the case of a concurrent
***************
*** 284,297 ****
</term>
<listitem>
<para>
! An internal lock mode acquiring automatically over tables
being queried. <productname>Postgres</productname>
! releases these locks after statement is
! done.
</para>

<para>
! Conflicts with AccessExclusiveLock only.
</para>
</listitem>
</varlistentry>
--- 284,296 ----
</term>
<listitem>
<para>
! An internal lock mode acquired automatically over tables
being queried. <productname>Postgres</productname>
! releases these locks after the statement is done.
</para>

<para>
! Conflicts only with AccessExclusiveLock.
</para>
</listitem>
</varlistentry>
***************
*** 423,429 ****
fields of a row are being updated (or deleted or marked for update).
<productname>Postgres</productname>
doesn't remember any information about modified rows in memory and
! so has no limit to the number of rows locked without lock escalation.
</para>

<para>
--- 422,428 ----
fields of a row are being updated (or deleted or marked for update).
<productname>Postgres</productname>
doesn't remember any information about modified rows in memory and
! so has no limit on the number of rows locked without lock escalation.
</para>

<para>
***************
*** 445,451 ****
Though <productname>Postgres</productname>
provides unblocking read/write access to table
data, unblocked read/write access is not provided for every
! index access methods implemented
in <productname>Postgres</productname>.
</para>

--- 444,450 ----
Though <productname>Postgres</productname>
provides unblocking read/write access to table
data, unblocked read/write access is not provided for every
! index access method implemented
in <productname>Postgres</productname>.
</para>

***************
*** 460,466 ****
<listitem>
<para>
Share/exclusive index-level locks are used for read/write access.
! Locks are released after statement is done.
</para>
</listitem>
</varlistentry>
--- 459,465 ----
<listitem>
<para>
Share/exclusive index-level locks are used for read/write access.
! Locks are released after the statement is done.
</para>
</listitem>
</varlistentry>
***************
*** 472,482 ****
<listitem>
<para>
Share/exclusive page-level locks are used for read/write access.
! Locks are released after page is processed.
</para>

<para>
! Page-level locks produces better concurrency than index-level ones
but are subject to deadlocks.
</para>
</listitem>
--- 471,481 ----
<listitem>
<para>
Share/exclusive page-level locks are used for read/write access.
! Locks are released after the page is processed.
</para>

<para>
! Page-level locks produce better concurrency than index-level ones
but are subject to deadlocks.
</para>
</listitem>
***************
*** 508,525 ****

<para>
Because readers in <productname>Postgres</productname>
! don't lock data, regardless of
! transaction isolation level, data read by one transaction can be
! overwritten by another. In the other words, if a row is returned
! by <command>SELECT</command> it doesn't mean that this row really
! exists at the time it is returned (i.e. sometime after the
statement or transaction began) nor
! that the row is protected from deletion or update by concurrent
transactions before the current transaction does a commit or rollback.
</para>

<para>
! To ensure the actual existance of a row and protect it against
concurrent updates one must use <command>SELECT FOR UPDATE</command> or
an appropriate <command>LOCK TABLE</command> statement.
This should be taken into account when porting applications using
--- 507,525 ----

<para>
Because readers in <productname>Postgres</productname>
! don't lock data, data read by one transaction can be
! overwritten by another, regardless of transaction isolation level.
! In other words, when a row is returned
! by <command>SELECT</command>, this row does not necessarily still
! exist at the time it is returned (i.e. sometime after the
statement or transaction began) nor
! is that row protected from deletion or update by concurrent
transactions before the current transaction does a commit or rollback.
+ <comment>Have I retained the proper meaning of this paragraph?</comment>
</para>

<para>
! To ensure the actual existence of a row and protect it against
concurrent updates one must use <command>SELECT FOR UPDATE</command> or
an appropriate <command>LOCK TABLE</command> statement.
This should be taken into account when porting applications using
diff -cr doc/src/sgml.orig/oper.sgml doc/src/sgml/oper.sgml
*** doc/src/sgml.orig/oper.sgml Mon Jul 19 10:49:26 1999
--- doc/src/sgml/oper.sgml Mon Jul 19 10:50:11 1999
***************
*** 60,66 ****
Operators have a precedence which is currently hardcoded into the parser.
Most operators have the same precedence and are left-associative. This may lead
to non-intuitive behavior; for example the boolean operators "&lt;" and "&gt;"
! have a different precedence that the boolean operators "&lt;=" and "&gt;=".

<table tocentry="1">
<title>
--- 60,66 ----
Operators have a precedence which is currently hardcoded into the parser.
Most operators have the same precedence and are left-associative. This may lead
to non-intuitive behavior; for example the boolean operators "&lt;" and "&gt;"
! have a different precedence from the boolean operators "&lt;=" and "&gt;=".

<table tocentry="1">
<title>
diff -cr doc/src/sgml.orig/query.sgml doc/src/sgml/query.sgml
*** doc/src/sgml.orig/query.sgml Mon Jul 19 10:27:30 1999
--- doc/src/sgml/query.sgml Mon Jul 19 10:35:28 1999
***************
*** 39,49 ****
% psql -s mydb
Welcome to the POSTGRESQL interactive sql monitor:
Please read the file COPYRIGHT for copyright terms of POSTGRESQL

type \? for help on slash commands
type \q to quit
type \g or terminate with semicolon to execute query
! You are currently connected to the database: postgres

mydb=> \i basics.sql
</ProgramListing>
--- 39,50 ----
% psql -s mydb
Welcome to the POSTGRESQL interactive sql monitor:
Please read the file COPYRIGHT for copyright terms of POSTGRESQL
+ [PostgreSQL 6.5.0 on i686-pc-linux-gnu, compiled by gcc egcs-2.91.66]

type \? for help on slash commands
type \q to quit
type \g or terminate with semicolon to execute query
! You are currently connected to the database: mydb

mydb=> \i basics.sql
</ProgramListing>
***************
*** 341,347 ****
DELETE FROM weather WHERE city = 'Hayward';
</ProgramListing>

! All weather recording belongs to Hayward is removed.
One should be wary of queries of the form
<ProgramListing>
DELETE FROM classname;
--- 342,348 ----
DELETE FROM weather WHERE city = 'Hayward';
</ProgramListing>

! All weather records belonging to Hayward are removed.
One should be wary of queries of the form
<ProgramListing>
DELETE FROM classname;
***************
*** 362,368 ****
<ProductName>PostgreSQL</ProductName> supports
aggregate functions.
The current implementation of
! <ProductName>Postgres</ProductName> aggregate functions have some limitations.
Specifically, while there are aggregates to compute
such functions as the <Function>count</Function>, <Function>sum</Function>,
<Function>avg</Function> (average), <Function>max</Function> (maximum) and
--- 363,369 ----
<ProductName>PostgreSQL</ProductName> supports
aggregate functions.
The current implementation of
! <ProductName>Postgres</ProductName> aggregate functions has some limitations.
Specifically, while there are aggregates to compute
such functions as the <Function>count</Function>, <Function>sum</Function>,
<Function>avg</Function> (average), <Function>max</Function> (maximum) and
diff -cr doc/src/sgml.orig/ref/abort.sgml doc/src/sgml/ref/abort.sgml
*** doc/src/sgml.orig/ref/abort.sgml Mon Jul 19 11:30:41 1999
--- doc/src/sgml/ref/abort.sgml Mon Jul 19 11:30:55 1999
***************
*** 18,24 ****
<DATE>1998-09-27</DATE>
</REFSYNOPSISDIVINFO>
<SYNOPSIS>
! ABORT
</SYNOPSIS>

<REFSECT2 ID="R2-SQL-ABORT-1">
--- 18,24 ----
<DATE>1998-09-27</DATE>
</REFSYNOPSISDIVINFO>
<SYNOPSIS>
! ABORT [TRANSACTION | WORK]
</SYNOPSIS>

<REFSECT2 ID="R2-SQL-ABORT-1">
***************
*** 83,88 ****
--- 83,92 ----
This command is identical
in behavior to the <acronym>SQL92</acronym> command <command>ROLLBACK</command>,
and is present only for historical reasons.
+ </para>
+ <para>
+ The keyword <command>TRANSACTION</command> or <command>WORK</command> is mere
+ noise and can be omitted.
</para>
<REFSECT2 ID="R2-SQL-ABORT-3">
<REFSECT2INFO>
diff -cr doc/src/sgml.orig/ref/alter_table.sgml doc/src/sgml/ref/alter_table.sgml
*** doc/src/sgml.orig/ref/alter_table.sgml Mon Jul 19 11:31:27 1999
--- doc/src/sgml/ref/alter_table.sgml Mon Jul 19 11:35:14 1999
***************
*** 85,91 ****
</TERM>
<LISTITEM>
<PARA>
! New name for an existing column.
</PARA>
</LISTITEM>
</VARLISTENTRY>
--- 85,91 ----
</TERM>
<LISTITEM>
<PARA>
! New name for an existing table.
</PARA>
</LISTITEM>
</VARLISTENTRY>
***************
*** 101,107 ****
Outputs
</TITLE>
<PARA>
-
<VARIABLELIST>
<VARLISTENTRY>
<TERM>
--- 101,106 ----
***************
*** 131,137 ****
</TERM>
<LISTITEM>
<PARA>
! Message returned if table or column is not available.
</para>
</listitem>
</VARLISTENTRY>
--- 130,136 ----
</TERM>
<LISTITEM>
<PARA>
! Message returned if the table or column is not available.
</para>
</listitem>
</VARLISTENTRY>
***************
*** 150,158 ****
<PARA>
<command>ALTER TABLE</command> changes the definition of an existing table.
The new columns and their types are specified in the same style
! and with the the same restrictions as in <command>CREATE TABLE</command>.
! The RENAME clause causes the name of a table or column
! to change without changing any of the data contained in
the affected table. Thus, the table or column will
remain of the same type and size after this command is
executed.
--- 149,157 ----
<PARA>
<command>ALTER TABLE</command> changes the definition of an existing table.
The new columns and their types are specified in the same style
! and with the same restrictions as in <command>CREATE TABLE</command>.
! The RENAME clause changes the name of a table or column
! without changing any of the data contained in
the affected table. Thus, the table or column will
remain of the same type and size after this command is
executed.
***************
*** 293,299 ****
specified by constraint from the definition of a table.
If RESTRICT is specified only a constraint with no dependent
constraints can be destroyed.
! If CASCADE is specified, Any constraints that are dependent on
this constraint are also dropped.
</para>

--- 292,298 ----
specified by constraint from the definition of a table.
If RESTRICT is specified only a constraint with no dependent
constraints can be destroyed.
! If CASCADE is specified, any constraints that depend on
this constraint are also dropped.
</para>

diff -cr doc/src/sgml.orig/sql.sgml doc/src/sgml/sql.sgml
*** doc/src/sgml.orig/sql.sgml Mon Jul 19 10:16:10 1999
--- doc/src/sgml/sql.sgml Mon Jul 19 10:24:29 1999
***************
*** 344,351 ****
In the previous section (<xref linkend="formal-notion" endterm="formal-notion">)
we defined the mathematical notion of
the relational model. Now we know how the data can be stored using a
! relational data model but we do not know what to do with all these
! tables to retrieve something from the database yet. For example somebody
could ask for the names of all suppliers that sell the part
'Screw'. Therefore two rather different kinds of notations for
expressing operations on relations have been defined:
--- 344,351 ----
In the previous section (<xref linkend="formal-notion" endterm="formal-notion">)
we defined the mathematical notion of
the relational model. Now we know how the data can be stored using a
! relational data model but we do not yet know what to do with all these
! tables to retrieve something from the database. For example somebody
could ask for the names of all suppliers that sell the part
'Screw'. Therefore two rather different kinds of notations for
expressing operations on relations have been defined:
***************
*** 479,485 ****
(&sigma;<subscript>R.C = S.C</subscript>).
Now we have a table
that contains the attribute <classname>C</classname>
! two times and we correct this by
projecting out the duplicate column.
</para>

--- 479,485 ----
(&sigma;<subscript>R.C = S.C</subscript>).
Now we have a table
that contains the attribute <classname>C</classname>
! twice and we correct this by
projecting out the duplicate column.
</para>

***************
*** 1218,1224 ****

<para>
When we look at the above query we can see
! the keyword SELECT two times. The first one at the beginning of the
query - we will refer to it as outer SELECT - and the one in the WHERE
clause which begins a nested query - we will refer to it as inner
SELECT. For every tuple of the outer SELECT the inner SELECT has to be
--- 1218,1224 ----

<para>
When we look at the above query we can see
! the keyword SELECT twice. The first one at the beginning of the
query - we will refer to it as outer SELECT - and the one in the WHERE
clause which begins a nested query - we will refer to it as inner
SELECT. For every tuple of the outer SELECT the inner SELECT has to be
***************
*** 1303,1309 ****
SNO | SNAME | CITY
-----+-------+--------
2 | Jones | Paris
! The only tuple returned by both parts of the query is the one having $SNO=2$.
</programlisting>
</para>

--- 1303,1309 ----
SNO | SNAME | CITY
-----+-------+--------
2 | Jones | Paris
! The only tuple returned by both parts of the query is the one having S.SNO=2.
</programlisting>
</para>

***************
*** 1490,1498 ****

<para>
The created index is maintained automatically, i.e. whenever a new tuple
! is inserted into the relation SUPPLIER the index I is adapted. Note
! that the only changes a user can percept when an index is present
! are an increased speed.
</para>
</example>
</para>
--- 1490,1498 ----

<para>
The created index is maintained automatically, i.e. whenever a new tuple
! is inserted into the relation SUPPLIER the index I is adapted.
! The only change a user can perceive when an index is present
! is increased speed.
</para>
</example>
</para>
***************
*** 1618,1624 ****
</para>

<para>
! Finally to destroy a given view use the command DROP VIEW:

<programlisting>
DROP VIEW <replaceable class="parameter">view_name</replaceable>;
--- 1618,1624 ----
</para>

<para>
! Finally to destroy a given view, use the command DROP VIEW:

<programlisting>
DROP VIEW <replaceable class="parameter">view_name</replaceable>;
***************
*** 1672,1678 ****
<title>Update</title>

<para>
! To change one or more attribute values of tuples in a relation the
UPDATE command is used. The syntax is:

<programlisting>
--- 1672,1678 ----
<title>Update</title>

<para>
! To change one or more attribute values of tuples in a relation, the
UPDATE command is used. The syntax is:

<programlisting>
***************
*** 1685,1691 ****

<para>
To change the value of attribute PRICE of the part 'Screw' in the
! relation PART we use:

<programlisting>
UPDATE PART
--- 1685,1691 ----

<para>
To change the value of attribute PRICE of the part 'Screw' in the
! relation PART, we use:

<programlisting>
UPDATE PART
***************
*** 1714,1720 ****
</para>

<para>
! To delete the supplier called 'Smith' of the table SUPPLIER the
following statement is used:

<programlisting>
--- 1714,1721 ----
</para>

<para>
! To delete all the suppliers called 'Smith' from the table SUPPLIER
! (in our example there is only one), the
following statement is used:

<programlisting>
***************
*** 1722,1727 ****
--- 1723,1734 ----
WHERE SNAME = 'Smith';
</programlisting>
</para>
+
+ <para>
+ Beware that UPDATE and DELETE can operate on many tuples; if the
+ condition is omitted or wrongly stated, many unintended changes may
+ be made.
+ </para>
</sect3>
</sect2>

***************
*** 1729,1737 ****
<title id="catalogs-title">System Catalogs</title>

<para>
! In every <acronym>SQL</acronym> database system
<firstterm>system catalogs</firstterm> are used to keep
! track of which tables, views indexes etc. are defined in the
database. These system catalogs can be queried as if they were normal
relations. For example there is one catalog used for the definition of
views. This catalog stores the query from the view definition. Whenever
--- 1736,1744 ----
<title id="catalogs-title">System Catalogs</title>

<para>
! In every <acronym>SQL</acronym> database system,
<firstterm>system catalogs</firstterm> are used to keep
! track of which tables, views, indexes etc. are defined in the
database. These system catalogs can be queried as if they were normal
relations. For example there is one catalog used for the definition of
views. This catalog stores the query from the view definition. Whenever
***************
*** 1784,1790 ****
<para>
A program using embedded <acronym>SQL</acronym>
in a host language consists of statements
! of the host language and of
<firstterm>embedded <acronym>SQL</acronym></firstterm>
(<acronym>ESQL</acronym>) statements. Every <acronym>ESQL</acronym>
statement begins with the keywords <command>EXEC SQL</command>.
--- 1791,1797 ----
<para>
A program using embedded <acronym>SQL</acronym>
in a host language consists of statements
! of the host language and
<firstterm>embedded <acronym>SQL</acronym></firstterm>
(<acronym>ESQL</acronym>) statements. Every <acronym>ESQL</acronym>
statement begins with the keywords <command>EXEC SQL</command>.
diff -cr doc/src/sgml.orig/start.sgml doc/src/sgml/start.sgml
*** doc/src/sgml.orig/start.sgml Mon Jul 19 10:25:11 1999
--- doc/src/sgml/start.sgml Mon Jul 19 10:26:28 1999
***************
*** 61,74 ****
a variant of the Berkeley C shell, such as csh or tcsh,
you would add
<ProgramListing>
! % set path = ( /usr/local/pgsql/bin path )
</ProgramListing>
in the <FileName>.login</FileName> file in your home directory. If you use
a variant of the Bourne shell, such as sh, ksh, or
bash, then you would add
<ProgramListing>
! % PATH=/usr/local/pgsql/bin:$PATH
! % export PATH
</ProgramListing>
to the .profile file in your home directory.
From now on, we will assume that you have added the
--- 61,74 ----
a variant of the Berkeley C shell, such as csh or tcsh,
you would add
<ProgramListing>
! set path = ( /usr/local/pgsql/bin path )
</ProgramListing>
in the <FileName>.login</FileName> file in your home directory. If you use
a variant of the Bourne shell, such as sh, ksh, or
bash, then you would add
<ProgramListing>
! PATH=/usr/local/pgsql/bin:$PATH
! export PATH
</ProgramListing>
to the .profile file in your home directory.
From now on, we will assume that you have added the
diff -cr doc/src/sgml.orig/syntax.sgml doc/src/sgml/syntax.sgml
*** doc/src/sgml.orig/syntax.sgml Mon Jul 19 10:36:34 1999
--- doc/src/sgml/syntax.sgml Mon Jul 19 10:38:50 1999
***************
*** 55,63 ****
<tip>
<para>
Any string can be specified as an identifier if surrounded by
! double quotes (<quote>like this!</quote>). Some care is required since
such an identifier will be case sensitive
! and will retain embedded whitespace other special characters.
</para>
</tip>

--- 55,65 ----
<tip>
<para>
Any string can be specified as an identifier if surrounded by
! double quotes (<quote>like this!</quote>).
! <comment>No quotes in printed version from postscript</comment>
! Some care is required since
such an identifier will be case sensitive
! and will retain embedded whitespace and other special characters.
</para>
</tip>

***************
*** 159,165 ****
The following are either <acronym>SQL92</acronym>
or <acronym>SQL3</acronym> reserved key words
which are not key words in <productname>Postgres</productname>.
! These have no proscribed usage in <productname>Postgres</productname>
at the time of writing (v6.5) but may become reserved key words in the
future:

--- 161,167 ----
The following are either <acronym>SQL92</acronym>
or <acronym>SQL3</acronym> reserved key words
which are not key words in <productname>Postgres</productname>.
! These have no prescribed usage in <productname>Postgres</productname>
at the time of writing (v6.5) but may become reserved key words in the
future:

***************
*** 203,209 ****
<para>
<acronym>SQL92</acronym> and <acronym>SQL3</acronym> have
<firstterm>non-reserved keywords</firstterm> which have
! a proscribed meaning in the language but which are also allowed
as identifiers.
<productname>Postgres</productname> has additional keywords
which allow similar unrestricted usage.
--- 205,211 ----
<para>
<acronym>SQL92</acronym> and <acronym>SQL3</acronym> have
<firstterm>non-reserved keywords</firstterm> which have
! a prescribed meaning in the language but which are also allowed
as identifiers.
<productname>Postgres</productname> has additional keywords
which allow similar unrestricted usage.
diff -cr doc/src/sgml.orig/typeconv.sgml doc/src/sgml/typeconv.sgml
*** doc/src/sgml.orig/typeconv.sgml Mon Jul 19 10:53:32 1999
--- doc/src/sgml/typeconv.sgml Mon Jul 19 11:02:23 1999
***************
*** 12,20 ****
In many cases a user will not need
to understand the details of the type conversion mechanism.
However, the implicit conversions done by <productname>Postgres</productname>
! can affect the apparent results of a query, and these results
! can be tailored by a user or programmer
! using <emphasis>explicit</emphasis> type coersion.
</para>

<para>
--- 12,20 ----
In many cases a user will not need
to understand the details of the type conversion mechanism.
However, the implicit conversions done by <productname>Postgres</productname>
! can affect the apparent results of a query, and a user or programmer
! can tailor these results by
! using <emphasis>explicit</emphasis> type coercion.
</para>

<para>
***************
*** 26,32 ****

<para>
The Programmer's Guide has more details on the exact algorithms used for
! implicit type conversion and coersion.
</para>

<sect1>
--- 26,32 ----

<para>
The Programmer's Guide has more details on the exact algorithms used for
! implicit type conversion and coercion.
</para>

<sect1>
***************
*** 38,44 ****
<productname>Postgres</productname> has an extensible type system which is
much more general and flexible than other <acronym>RDBMS</acronym> implementations.
Hence, most type conversion behavior in <productname>Postgres</productname>
! should be governed by general rules rather than by ad-hoc heuristics to allow
mixed-type expressions to be meaningful, even with user-defined types.
</para>

--- 38,45 ----
<productname>Postgres</productname> has an extensible type system which is
much more general and flexible than other <acronym>RDBMS</acronym> implementations.
Hence, most type conversion behavior in <productname>Postgres</productname>
! should be governed by general rules rather than by ad-hoc heuristics,
! in order to allow
mixed-type expressions to be meaningful, even with user-defined types.
</para>

***************
*** 59,65 ****
</programlisting>

has two strings, of type <type>text</type> and <type>point</type>.
! If a type is not specified, then the placeholder type <type>unknown</type>
is assigned initially, to be resolved in later stages as described below.
</para>

--- 60,66 ----
</programlisting>

has two strings, of type <type>text</type> and <type>point</type>.
! If a type is not specified, the placeholder type <type>unknown</type>
is assigned initially, to be resolved in later stages as described below.
</para>

***************
*** 100,107 ****
</term>
<listitem>
<para>
! <acronym>SQL</acronym> INSERT statements place the results of query into a table. The expressions
! in the query must be matched up with, and perhaps converted to, the target columns of the insert.
</para>
</listitem>
</varlistentry>
--- 101,108 ----
</term>
<listitem>
<para>
! <acronym>SQL</acronym> INSERT statements place the results of a query into a table. The expressions
! in the query must be matched up with, and perhaps converted to, the target columns of the insertion.
</para>
</listitem>
</varlistentry>
***************
*** 121,128 ****
<para>
Many of the general type conversion rules use simple conventions built on
the <productname>Postgres</productname> function and operator system tables.
! There are some heuristics included in the conversion rules to better support
! conventions for the <acronym>SQL92</acronym> standard native types such as
<type>smallint</type>, <type>integer</type>, and <type>float</type>.
</para>

--- 122,129 ----
<para>
Many of the general type conversion rules use simple conventions built on
the <productname>Postgres</productname> function and operator system tables.
! There are some heuristics included in the conversion rules to improve support
! for the <acronym>SQL92</acronym> standard native types such as
<type>smallint</type>, <type>integer</type>, and <type>float</type>.
</para>

***************
*** 163,176 ****
<itemizedlist mark="bullet" spacing="compact">
<listitem>
<para>
! Implicit conversions should never have suprising or unpredictable outcomes.
</para>
</listitem>

<listitem>
<para>
! User-defined types, of which the parser has no apriori knowledge, should be
! "higher" in the type heirarchy. In mixed-type expressions, native types shall always
be converted to a user-defined type (of course, only if conversion is necessary).
</para>
</listitem>
--- 164,177 ----
<itemizedlist mark="bullet" spacing="compact">
<listitem>
<para>
! Implicit conversions should never have surprising or unpredictable outcomes.
</para>
</listitem>

<listitem>
<para>
! User-defined types, of which the parser has no a priori knowledge, should be
! "higher" in the type hierarchy. In mixed-type expressions, native types will always
be converted to a user-defined type (of course, only if conversion is necessary).
</para>
</listitem>
***************
*** 188,202 ****
<para>
There should be no extra overhead from the parser or executor
if a query does not need implicit type conversion.
! That is, if a query is well formulated and the types already match up, then the query should proceed
without spending extra time in the parser and without introducing unnecessary implicit conversion
functions into the query.
</para>

<para>
Additionally, if a query usually requires an implicit conversion for a function, and
! if then the user defines an explicit function with the correct argument types, the parser
! should use this new function and will no longer do the implicit conversion using the old function.
</para>
</listitem>
</itemizedlist>
--- 189,203 ----
<para>
There should be no extra overhead from the parser or executor
if a query does not need implicit type conversion.
! That is, if a query is well formulated and the types already match, the query should proceed
without spending extra time in the parser and without introducing unnecessary implicit conversion
functions into the query.
</para>

<para>
Additionally, if a query usually requires an implicit conversion for a function, and
! if the user then defines an explicit function with the correct argument types, the parser
! will use this new function and no longer do the implicit conversion using the old function.
</para>
</listitem>
</itemizedlist>
***************
*** 223,236 ****
<step performance="optional">
<para>
If one argument of a binary operator is <type>unknown</type>,
! then assume it is the same type as the other argument.
</para>
</step>
<step performance="required">
<para>
Reverse the arguments, and look for an exact match with an operator which
points to itself as being commutative.
! If found, then reverse the arguments in the parse tree and use this operator.
</para>
</step>
</substeps>
--- 224,237 ----
<step performance="optional">
<para>
If one argument of a binary operator is <type>unknown</type>,
! assume it is the same type as the other argument.
</para>
</step>
<step performance="required">
<para>
Reverse the arguments, and look for an exact match with an operator which
points to itself as being commutative.
! If one is found, reverse the arguments in the parse tree and use this operator.
</para>
</step>
</substeps>
***************
*** 265,271 ****
boolean, numeric, string, geometric, or user-defined. If there is a mix of
categories, or more than one user-defined type, throw an error because
the correct choice cannot be deduced without more clues.
! If only one category is present, then assign the "preferred type"
to the input column which had been previously "unknown".
</para>
</step>
--- 266,272 ----
boolean, numeric, string, geometric, or user-defined. If there is a mix of
categories, or more than one user-defined type, throw an error because
the correct choice cannot be deduced without more clues.
! If only one category is present, assign the "preferred type"
to the input column which had been previously "unknown".
</para>
</step>
***************
*** 274,280 ****
Choose the candidate with the most exact type matches, and which matches
the "preferred type" for each column category from the previous step.
If there is still more than one candidate, or if there are none,
! then throw an error.
</para>
</step>
</substeps>
--- 275,281 ----
Choose the candidate with the most exact type matches, and which matches
the "preferred type" for each column category from the previous step.
If there is still more than one candidate, or if there are none,
! throw an error.
</para>
</step>
</substeps>
***************
*** 378,386 ****

<note>
<para>
! If a user defines a new type and defines an operator <quote>||</quote> to work
! with it, then this query would no longer succeed as written. The parser would
! now have candidate types from two categories, and could not decide which to use.
</para>
</note>
</sect3>
--- 379,388 ----

<note>
<para>
! If a user defined a new type and defined an operator <quote>||</quote> to work
! with it, this query would no longer succeed as written. The parser would
! now have candidate types from two categories, and would not be able to
! decide which to use.
</para>
</note>
</sect3>
***************
*** 455,461 ****
boolean, numeric, string, geometric, or user-defined. If there is a mix of
categories, or more than one user-defined type, throw an error because
the correct choice cannot be deduced without more clues.
! If only one category is present, then assign the "preferred type"
to the input column which had been previously "unknown".
</para></step>
<step performance="required">
--- 457,463 ----
boolean, numeric, string, geometric, or user-defined. If there is a mix of
categories, or more than one user-defined type, throw an error because
the correct choice cannot be deduced without more clues.
! If only one category is present, assign the "preferred type"
to the input column which had been previously "unknown".
</para></step>
<step performance="required">
***************
*** 463,469 ****
Choose the candidate with the most exact type matches, and which matches
the "preferred type" for each column category from the previous step.
If there is still more than one candidate, or if there are none,
! then throw an error.
</para></step>
</substeps>
</step>
--- 465,471 ----
Choose the candidate with the most exact type matches, and which matches
the "preferred type" for each column category from the previous step.
If there is still more than one candidate, or if there are none,
! throw an error.
</para></step>
</substeps>
</step>
***************
*** 520,526 ****

<para>
If the string is declared to be of type <type>varchar</type>, as might be the case
! if it comes from a table, then the parser will try to coerce it to become <type>text</type>:
<programlisting>
tgl=> select substr(varchar '1234', 3);
substr
--- 522,528 ----

<para>
If the string is declared to be of type <type>varchar</type>, as might be the case
! if it comes from a table, the parser will try to coerce it to become <type>text</type>:
<programlisting>
tgl=> select substr(varchar '1234', 3);
substr
diff -cr doc/src/sgml.orig/y2k.sgml doc/src/sgml/y2k.sgml
*** doc/src/sgml.orig/y2k.sgml Mon Jul 19 10:15:07 1999
--- doc/src/sgml/y2k.sgml Mon Jul 19 10:15:30 1999
***************
*** 14,20 ****
<para>
The <productname>PostgreSQL</productname> Global Development Team provides
the <productname>Postgres</productname> software code tree as a public service,
! without warranty and without liability for it's behavior or performance.
However, at the time of writing:
</para>

--- 14,20 ----
<para>
The <productname>PostgreSQL</productname> Global Development Team provides
the <productname>Postgres</productname> software code tree as a public service,
! without warranty and without liability for its behavior or performance.
However, at the time of writing:
</para>

--
Vote against SPAM: http://www.politik-digital.de/spam/
========================================
Oliver Elphick Oliver(dot)Elphick(at)lfix(dot)co(dot)uk
Isle of Wight http://www.lfix.co.uk/oliver
PGP key from public servers; key ID 32B8FAA1
========================================
"Blessed is the man that trusteth in the LORD, and
whose hope the LORD is." Jeremiah 17:7