Update documentation to reflect the fact that ORDER BY, GROUP BY, etc

[postgresql] / doc / src / sgml / ref / select.sgml

diff --git a/doc/src/sgml/ref/select.sgml b/doc/src/sgml/ref/select.sgml
index f983b2a8213f916f1be22edbf2df61afb38d2c8f..04d2a36e5b337c6dc706713bb230649e922b20f4 100644 (file)
--- a/doc/src/sgml/ref/select.sgml
+++ b/doc/src/sgml/ref/select.sgml
@@ -1,5 +1,5 @@
 <!--
-$Header: /cvsroot/pgsql/doc/src/sgml/ref/select.sgml,v 1.67 2003/05/04 02:23:16 petere Exp $
+$Header: /cvsroot/pgsql/doc/src/sgml/ref/select.sgml,v 1.68 2003/08/17 22:09:00 tgl Exp $
 PostgreSQL documentation
 -->
 
@@ -660,8 +660,11 @@ SELECT name FROM distributors ORDER BY code;
     <literal>ORDER BY</> clause.  If not specified, <literal>ASC</> is
     assumed by default.  Alternatively, a specific ordering operator
     name may be specified in the <literal>USING</> clause.
-    <literal>ASC</> is equivalent to <literal>USING &lt;</> and
-    <literal>DESC</> is equivalent to <literal>USING &gt;</>.
+    <literal>ASC</> is usually equivalent to <literal>USING &lt;</> and
+    <literal>DESC</> is usually equivalent to <literal>USING &gt;</>.
+    (But the creator of a user-defined datatype can define exactly what the
+    default sort ordering is, and it might correspond to operators with other
+    names.)
    </para>
 
    <para>
@@ -671,7 +674,7 @@ SELECT name FROM distributors ORDER BY code;
    </para>
 
    <para>
-    Data of character types is sorted according to the locale-specific
+    Character-string data is sorted according to the locale-specific
     collation order that was established when the database cluster
     was initialized.
    </para>
@@ -1003,7 +1006,9 @@ SELECT distributors.* FROM distributors d, distributors distributors;
     that he will actually get.  To help detect this sort of mistake,
     PostgreSQL will warn if the implicit-<literal>FROM</literal>
     feature is used in a <command>SELECT</command> statement that also
-    contains an explicit <literal>FROM</literal> clause.
+    contains an explicit <literal>FROM</literal> clause.  Also, it is
+    possible to disable the implicit-<literal>FROM</literal> feature
+    by setting the <varname>ADD_MISSING_FROM</> parameter to false.
    </para>
   </refsect2>
 
@@ -1015,7 +1020,7 @@ SELECT distributors.* FROM distributors d, distributors distributors;
     noise and can be omitted without affecting the meaning.  The
     <productname>PostgreSQL</productname> parser requires this key
     word when renaming output columns because the type extensibility
-    features lead to parsing ambiguities in this context.
+    features lead to parsing ambiguities without it.
     <literal>AS</literal> is optional in <literal>FROM</literal>
     items, however.
    </para>
@@ -1025,7 +1030,7 @@ SELECT distributors.* FROM distributors d, distributors distributors;
    <title>Namespace Available to <literal>GROUP BY</literal> and <literal>ORDER BY</literal></title>
 
    <para>
-    In the SQL standard, an <literal>ORDER BY</literal> clause may
+    In the SQL92 standard, an <literal>ORDER BY</literal> clause may
     only use result column names or numbers, while a <literal>GROUP
     BY</literal> clause may only use expressions based on input column
     names.  <productname>PostgreSQL</productname> extends each of
@@ -1036,6 +1041,13 @@ SELECT distributors.* FROM distributors d, distributors distributors;
     expression will always be taken as input-column names, not as
     result-column names.
    </para>
+
+   <para>
+    SQL99 uses a slightly different definition which is not upward compatible
+    with SQL92.  In most cases, however, <productname>PostgreSQL</productname>
+    will interpret an <literal>ORDER BY</literal> or <literal>GROUP
+    BY</literal> expression the same way SQL99 does.
+   </para>
   </refsect2>
 
   <refsect2>