dirbacke
diff --git a/‎doc/src/sgml/ddl.sgml
Lines changed: 15 additions & 12 deletions b/‎doc/src/sgml/ddl.sgml
Lines changed: 15 additions & 12 deletions
diff --git a/‎doc/src/sgml/queries.sgml
Lines changed: 3 additions & 3 deletions b/‎doc/src/sgml/queries.sgml
Lines changed: 3 additions & 3 deletions
diff --git a/‎doc/src/sgml/syntax.sgml
Lines changed: 10 additions & 13 deletions b/‎doc/src/sgml/syntax.sgml
Lines changed: 10 additions & 13 deletions
diff --git a/‎doc/src/sgml/typeconv.sgml
Lines changed: 14 additions & 11 deletions b/‎doc/src/sgml/typeconv.sgml
Lines changed: 14 additions & 11 deletions
@@ -1,4 +1,4 @@
-<!-- $Header: /cvsroot/pgsql/doc/src/sgml/ddl.sgml,v 1.16 2003/08/10 01:20:34 tgl Exp $ -->
+<!-- $Header: /cvsroot/pgsql/doc/src/sgml/ddl.sgml,v 1.17 2003/08/14 23:13:27 tgl Exp $ -->
 
 <chapter id="ddl">
  <title>Data Definition</title>
@@ -490,7 +490,7 @@ CREATE TABLE products (
     price numeric NOT NULL CHECK (price > 0)
 );
 </programlisting>
-    The order doesn't matter.  It does not necessarily affect in which
+    The order doesn't matter.  It does not necessarily determine in which
     order the constraints are checked.
    </para>
 
@@ -578,7 +578,7 @@ CREATE TABLE products (
     least) two rows in the table where the values of each of the
     corresponding columns that are part of the constraint are equal.
     However, null values are not considered equal in this
-    consideration.  That means, in the presence of a multicolumn
+    consideration.  That means even in the presence of a
     unique constraint it is possible to store an unlimited number of
     rows that contain a null value in at least one of the constrained
     columns.  This behavior conforms to the SQL standard, but we have
@@ -629,7 +629,7 @@ CREATE TABLE example (
     A primary key indicates that a column or group of columns can be
     used as a unique identifier for rows in the table.  (This is a
     direct consequence of the definition of a primary key.  Note that
-    a unique constraint does not, in fact, provide a unique identifier
+    a unique constraint does not, by itself, provide a unique identifier
     because it does not exclude null values.)  This is useful both for
     documentation purposes and for client applications.  For example,
     a GUI application that allows modifying row values probably needs
@@ -850,8 +850,9 @@ CREATE TABLE capitals (
    In this case, a row  of  capitals  <firstterm>inherits</firstterm>  all
    attributes  (name,  population,  and altitude) from its
    parent, cities.  The type  of  the  attribute  name  is
-   <type>text</type>,  a  native  <productname>PostgreSQL</productname>  type  for variable length
-   ASCII strings.  The type of the attribute population is
+   <type>text</type>,  a  native  <productname>PostgreSQL</productname>  type
+   for variable length character strings.  The type of the attribute
+   population is
    <type>float</type>,  a  native <productname>PostgreSQL</productname> type for double precision
    floating-point numbers.  State capitals have  an  extra
    attribute, state, that shows their state.  In <productname>PostgreSQL</productname>,
@@ -964,7 +965,7 @@ WHERE c.altitude &gt; 500 and c.tableoid = p.oid;
    <para>
      In previous versions of <productname>PostgreSQL</productname>, the
      default was not to get access to child tables. This was found to
-     be error prone and is also in violation of the SQL standard. Under the old
+     be error prone and is also in violation of the SQL99 standard. Under the old
      syntax, to get the sub-tables you append <literal>*</literal> to the table name.
      For example
 <programlisting>
@@ -1180,7 +1181,8 @@ ALTER TABLE products RENAME TO items;
   <note>
    <para>
     To change the owner of a table, index, sequence, or view, use the
-    <command>ALTER TABLE</command> command.
+    <xref linkend="sql-altertable" endterm="sql-altertable-title">
+    command.
    </para>
   </note>
 
@@ -1192,7 +1194,8 @@ ALTER TABLE products RENAME TO items;
    <literal>USAGE</>, and <literal>ALL PRIVILEGES</>. For complete
    information on the different types of privileges supported by
    <productname>PostgreSQL</productname>, refer to the
-   <command>GRANT</command> reference page.  The following sections
+   <xref linkend="sql-grant" endterm="sql-grant-title">
+   reference page.  The following sections
    and chapters will also show you how those privileges are used.
   </para>
 
@@ -1453,8 +1456,8 @@ SHOW search_path;
  $user,public
 </screen>
     The first element specifies that a schema with the same name as
-    the current user is to be searched.  Since no such schema exists
-    yet, this entry is ignored.  The second element refers to the
+    the current user is to be searched.  If no such schema exists,
+    the entry is ignored.  The second element refers to the
     public schema that we have seen already.
    </para>
 
@@ -1737,7 +1740,7 @@ DROP TABLE products CASCADE;
    the possible dependencies varies with the type of the object.  You
    can also write <literal>RESTRICT</literal> instead of
    <literal>CASCADE</literal> to get the default behavior which is to
-   restrict drops of objects that other objects depend on.
+   prevent drops of objects that other objects depend on.
   </para>
 
   <note>
 
@@ -1,4 +1,4 @@
-<!-- $Header: /cvsroot/pgsql/doc/src/sgml/queries.sgml,v 1.21 2003/04/10 01:22:44 petere Exp $ -->
+<!-- $Header: /cvsroot/pgsql/doc/src/sgml/queries.sgml,v 1.22 2003/08/14 23:13:27 tgl Exp $ -->
 
 <chapter id="queries">
  <title>Queries</title>
@@ -1208,10 +1208,10 @@ SELECT <replaceable>select_list</replaceable>
   </para>
 
   <para>
-   When using <literal>LIMIT</>, it is a good idea to use an
+   When using <literal>LIMIT</>, it is important to use an
    <literal>ORDER BY</> clause that constrains the result rows into a
    unique order.  Otherwise you will get an unpredictable subset of
-   the query's rows. --- You may be asking for the tenth through
+   the query's rows. You may be asking for the tenth through
    twentieth rows, but tenth through twentieth in what ordering?  The
    ordering is unknown, unless you specified <literal>ORDER BY</>.
   </para>
 
@@ -1,5 +1,5 @@
 <!--
-$Header: /cvsroot/pgsql/doc/src/sgml/syntax.sgml,v 1.81 2003/08/09 22:50:22 tgl Exp $
+$Header: /cvsroot/pgsql/doc/src/sgml/syntax.sgml,v 1.82 2003/08/14 23:13:27 tgl Exp $
 -->
 
 <chapter id="sql-syntax">
@@ -450,14 +450,7 @@ CAST ( '<replaceable>string</replaceable>' AS <replaceable>type</replaceable> )
 '{{1,2,3},{4,5,6},{7,8,9}}'
 </programlisting>
      This constant is a two-dimensional, 3-by-3 array consisting of three
-     subarrays of integers.
-    </para>
-
-    <para>
-     Individual array elements can be placed between double-quote
-     marks (<literal>"</literal>) <!-- " --> to avoid ambiguity
-     problems with respect to whitespace.  Without quote marks, the
-     array-value parser will skip leading whitespace.
+     subarrays of integers.  For more information see <xref linkend="arrays">.
     </para>
 
     <para>
@@ -1190,8 +1183,10 @@ CAST ( <replaceable>expression</replaceable> AS <replaceable>type</replaceable>
     one of the two standard cast syntaxes is used to do a run-time
     conversion, it will internally invoke a registered function to
     perform the conversion.  By convention, these conversion functions
-    have the same name as their output type, but this is not something
-    that a portable application should rely on.)
+    have the same name as their output type, and thus the <quote>function-like
+    syntax</> is nothing more than a direct invocation of the underlying
+    conversion function.  Obviously, this is not something that a portable
+    application should rely on.)
    </para>
   </sect2>
 
@@ -1349,8 +1344,10 @@ SELECT ... WHERE x &lt;&gt; 0 AND y/x &gt; 1.5;
 <programlisting>
 SELECT ... WHERE CASE WHEN x &lt;&gt; 0 THEN y/x &gt; 1.5 ELSE false END;
 </programlisting>
-    A <literal>CASE</> construct used in this fashion will defeat optimization attempts,
-    so it should only be done when necessary.
+    A <literal>CASE</> construct used in this fashion will defeat optimization
+    attempts, so it should only be done when necessary.  (In this particular
+    example, it would doubtless be best to sidestep the problem by writing
+    <literal>y &gt; 1.5*x</> instead.)
    </para>
   </sect2>
  </sect1>
 
@@ -1,5 +1,5 @@
 <!--
-$Header: /cvsroot/pgsql/doc/src/sgml/typeconv.sgml,v 1.31 2003/05/26 00:11:27 tgl Exp $
+$Header: /cvsroot/pgsql/doc/src/sgml/typeconv.sgml,v 1.32 2003/08/14 23:13:27 tgl Exp $
 -->
 
 <chapter Id="typeconv">
@@ -113,15 +113,16 @@ with, and perhaps converted to, the types of the target columns.
 </varlistentry>
 <varlistentry>
 <term>
-<literal>UNION</literal> and <literal>CASE</literal> constructs
+<literal>UNION</literal>, <literal>CASE</literal>, and <literal>ARRAY</literal> constructs
 </term>
 <listitem>
 <para>
-Since all query results from a unionized <literal>SELECT</literal> statement must appear in a single
-set of columns, the types of the results
-of each <literal>SELECT</> clause must be matched up and converted to a uniform set.
-Similarly, the branch expressions of a <literal>CASE</> construct must be converted to
-a common type so that the <literal>CASE</> expression as a whole has a known output type.
+Since all query results from a unionized <literal>SELECT</literal> statement
+must appear in a single set of columns, the types of the results of each
+<literal>SELECT</> clause must be matched up and converted to a uniform set.
+Similarly, the branch expressions of a <literal>CASE</> construct must be
+converted to a common type so that the <literal>CASE</> expression as a whole
+has a known output type.  The same holds for <literal>ARRAY</> constructs.
 </para>
 </listitem>
 </varlistentry>
@@ -754,20 +755,22 @@ padding spaces.
 </sect1>
 
 <sect1 id="typeconv-union-case">
-<title><literal>UNION</> and <literal>CASE</> Constructs</title>
+<title><literal>UNION</literal>, <literal>CASE</literal>, and
+<literal>ARRAY</literal> Constructs</title>
 
 <para>
 SQL <literal>UNION</> constructs must match up possibly dissimilar types to
 become a single result set.  The resolution algorithm is applied separately
 to each output column of a union query.  The <literal>INTERSECT</> and
 <literal>EXCEPT</> constructs resolve dissimilar types in the same way as
 <literal>UNION</>.
-A <literal>CASE</> construct also uses the identical algorithm to match up its
-component expressions and select a result data type.
+A <literal>CASE</> construct uses the identical algorithm to match up its
+component expressions and select a result data type, as does <literal>ARRAY</>.
 </para>
 
 <procedure>
-<title><literal>UNION</> and <literal>CASE</> Type Resolution</title>
+<title><literal>UNION</literal>, <literal>CASE</literal>, and
+<literal>ARRAY</literal> Type Resolution</title>
 
 <step performance="required">
 <para>