Merge documentation updates from 7.3 branch.

doc/src/sgml/advanced.sgml

@@ -1,5 +1,5 @@
 <!--
-$Header: /cvsroot/pgsql/doc/src/sgml/advanced.sgml,v 1.30 2002/10/24 17:48:54 petere Exp $
+$Header: /cvsroot/pgsql/doc/src/sgml/advanced.sgml,v 1.31 2002/11/11 20:14:02 petere Exp $
 -->
 
  <chapter id="tutorial-advanced">
@@ -46,14 +46,14 @@ $Header: /cvsroot/pgsql/doc/src/sgml/advanced.sgml,v 1.30 2002/10/24 17:48:54 pe
     <firstterm>view</firstterm> over the query, which gives a name to
     the query that you can refer to like an ordinary table.
 
-    <programlisting>
+<programlisting>
 CREATE VIEW myview AS
     SELECT city, temp_lo, temp_hi, prcp, date, location
         FROM weather, cities
         WHERE city = name;
 
 SELECT * FROM myview;
-    </programlisting>
+</programlisting>
    </para>
 
    <para>
@@ -101,7 +101,7 @@ SELECT * FROM myview;
    <para>
     The new declaration of the tables would look like this:
 
-    <programlisting>
+<programlisting>
 CREATE TABLE cities (
  	city     varchar(80) primary key,
 	 location point
@@ -114,23 +114,23 @@ CREATE TABLE weather (
 	prcp      real,
 	date      date
 );
-    </programlisting>
+</programlisting>
 
     Now try inserting an invalid record:
 
-    <programlisting>
+<programlisting>
 INSERT INTO weather VALUES ('Berkeley', 45, 53, 0.0, '1994-11-28');
-    </programlisting>
+</programlisting>
 
-    <screen>
+<screen>
 ERROR:  &lt;unnamed&gt; referential integrity violation - key referenced from weather not found in cities
-    </screen>
+</screen>
    </para>
 
    <para>
     The behavior of foreign keys can be finely tuned to your
     application.  We will not go beyond this simple example in this
-    tutorial, but just refer you to the &cite-reference;
+    tutorial, but just refer you to the &cite-user;
     for more information.  Making correct use of
     foreign keys will definitely improve the quality of your database
     applications, so you are strongly encouraged to learn about them.
@@ -161,7 +161,7 @@ ERROR:  &lt;unnamed&gt; referential integrity violation - key referenced from we
     to Bob's account.  Simplifying outrageously, the SQL commands for this
     might look like
 
-    <programlisting>
+<programlisting>
 UPDATE accounts SET balance = balance - 100.00
     WHERE name = 'Alice';
 UPDATE branches SET balance = balance - 100.00
@@ -170,7 +170,7 @@ UPDATE accounts SET balance = balance + 100.00
     WHERE name = 'Bob';
 UPDATE branches SET balance = balance + 100.00
     WHERE name = (SELECT branch_name FROM accounts WHERE name = 'Bob');
-    </programlisting>
+</programlisting>
    </para>
 
    <para>
@@ -222,13 +222,13 @@ UPDATE branches SET balance = balance + 100.00
     <command>BEGIN</> and <command>COMMIT</> commands.  So our banking
     transaction would actually look like
 
-    <programlisting>
+<programlisting>
 BEGIN;
 UPDATE accounts SET balance = balance - 100.00
     WHERE name = 'Alice';
 -- etc etc
 COMMIT;
-    </programlisting>
+</programlisting>
    </para>
 
    <para>
@@ -278,7 +278,7 @@ COMMIT;
     implicitly when you list all cities.  If you're really clever you
     might invent some scheme like this:
 
-    <programlisting>
+<programlisting>
 CREATE TABLE capitals (
   name       text,
   population real,
@@ -296,7 +296,7 @@ CREATE VIEW cities AS
   SELECT name, population, altitude FROM capitals
     UNION
   SELECT name, population, altitude FROM non_capitals;
-    </programlisting>
+</programlisting>
 
     This works OK as far as querying goes, but it gets ugly when you
     need to update several rows, to name one thing.
@@ -305,7 +305,7 @@ CREATE VIEW cities AS
    <para>
     A better solution is this:
 
-    <programlisting>
+<programlisting>
 CREATE TABLE cities (
   name       text,
   population real,
@@ -315,7 +315,7 @@ CREATE TABLE cities (
 CREATE TABLE capitals (
   state      char(2)
 ) INHERITS (cities);
-    </programlisting>
+</programlisting>
    </para>
 
    <para>
@@ -336,11 +336,11 @@ CREATE TABLE capitals (
     including  state capitals, that are located at an altitude 
     over 500 ft.:
 
-    <programlisting>
+<programlisting>
 SELECT name, altitude
   FROM cities
   WHERE altitude &gt; 500;
-    </programlisting>
+</programlisting>
 
     which returns:
 
@@ -359,11 +359,11 @@ SELECT name, altitude
     all  the cities that are not state capitals and
     are situated at an altitude of 500 ft. or higher:
 
-    <programlisting>
+<programlisting>
 SELECT name, altitude
     FROM ONLY cities
     WHERE altitude &gt; 500;
-    </programlisting>
+</programlisting>
 
 <screen>
    name    | altitude
@@ -380,7 +380,7 @@ SELECT name, altitude
     <classname>cities</classname> table, and not tables below
     <classname>cities</classname> in the inheritance hierarchy.  Many
     of the commands that we have already discussed --
-    <command>SELECT</command>, <command>UPDATE</command> and
+    <command>SELECT</command>, <command>UPDATE</command>, and
     <command>DELETE</command> -- support this <literal>ONLY</literal>
     notation.
    </para>