Remove pre-7.4 documentaiton mentions, now that 8.0 is the oldest

supported release.

doc/src/sgml/datatype.sgml

@@ -1,4 +1,4 @@
-<!-- $PostgreSQL: pgsql/doc/src/sgml/datatype.sgml,v 1.242 2010/02/17 04:19:37 tgl Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/datatype.sgml,v 1.243 2010/02/24 03:33:48 momjian Exp $ -->
 
  <chapter id="datatype">
   <title id="datatype-title">Data Types</title>
@@ -715,11 +715,7 @@ NUMERIC
 
     <note>
      <para>
-      Prior to <productname>PostgreSQL</productname> 7.4, the precision in
-      <type>float(<replaceable>p</replaceable>)</type> was taken to mean
-      so many <emphasis>decimal</> digits.  This has been corrected to match the SQL
-      standard, which specifies that the precision is measured in binary
-      digits.  The assumption that <type>real</type> and
+      The assumption that <type>real</type> and
       <type>double precision</type> have exactly 24 and 53 bits in the
       mantissa respectively is correct for IEEE-standard floating point
       implementations.  On non-IEEE platforms it might be off a little, but
@@ -795,11 +791,9 @@ ALTER SEQUENCE <replaceable class="parameter">tablename</replaceable>_<replaceab
 
     <note>
      <para>
-      Prior to <productname>PostgreSQL</productname> 7.3, <type>serial</type>
-      implied <literal>UNIQUE</literal>.  This is no longer automatic.  If
-      you wish a serial column to have a unique constraint or be a
-      primary key, it must now be specified, just like
-      any other data type.
+      If you wish a serial column to have a unique constraint or be
+      a primary key, it must be specified, just like any other data
+      type.
      </para>
     </note>
 
@@ -1521,14 +1515,6 @@ SELECT E'\\xDEADBEEF';
      </tgroup>
     </table>
 
-   <note>
-    <para>
-     Prior to <productname>PostgreSQL</productname> 7.3, writing just
-     <type>timestamp</type> was equivalent to <type>timestamp with
-     time zone</type>.  This was changed for SQL compliance.
-    </para>
-   </note>
-
    <para>
     <type>time</type>, <type>timestamp</type>, and
     <type>interval</type> accept an optional precision value

doc/src/sgml/ddl.sgml

@@ -1,4 +1,4 @@
-<!-- $PostgreSQL: pgsql/doc/src/sgml/ddl.sgml,v 1.88 2009/10/23 05:24:52 petere Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/ddl.sgml,v 1.89 2010/02/24 03:33:48 momjian Exp $ -->
 
 <chapter id="ddl">
  <title>Data Definition</title>
@@ -1795,18 +1795,12 @@ REVOKE CREATE ON SCHEMA public FROM PUBLIC;
    </para>
 
    <para>
-    In <productname>PostgreSQL</productname> versions before 7.3,
-    table names beginning with <literal>pg_</> were reserved.  This is
-    no longer true: you can create such a table name if you wish, in
-    any non-system schema.  However, it's best to continue to avoid
-    such names, to ensure that you won't suffer a conflict if some
-    future version defines a system table named the same as your
-    table.  (With the default search path, an unqualified reference to
-    your table name would then be resolved as the system table instead.)
-    System tables will continue to follow the convention of having
-    names beginning with <literal>pg_</>, so that they will not
-    conflict with unqualified user-table names so long as users avoid
-    the <literal>pg_</> prefix.
+    It is best to avoid table names beginning with <literal>pg_</>
+    because they might someday conflict with system catalogs of the
+    same name.  (<productname>PostgreSQL</productname> system catalog
+    table names always start with <literal>pg_</>).  Of course, table
+    names can always be schema-qualified to avoid conflicting with
+    system catalog table names.
    </para>
   </sect2>
 
@@ -3040,15 +3034,6 @@ DROP TABLE products CASCADE;
    </para>
   </note>
 
-  <note>
-   <para>
-    Foreign key constraint dependencies and serial column dependencies
-    from <productname>PostgreSQL</productname> versions prior to 7.3
-    are <emphasis>not</emphasis> maintained or created during the
-    upgrade process.  All other dependency types will be properly
-    created during an upgrade from a pre-7.3 database.
-   </para>
-  </note>
  </sect1>
 
 </chapter>

doc/src/sgml/libpq.sgml

@@ -1,4 +1,4 @@
-<!-- $PostgreSQL: pgsql/doc/src/sgml/libpq.sgml,v 1.300 2010/02/17 04:19:37 tgl Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/libpq.sgml,v 1.301 2010/02/24 03:33:49 momjian Exp $ -->
 
 <chapter id="libpq">
  <title><application>libpq</application> - C Library</title>
@@ -1203,14 +1203,6 @@ PQconninfoOption *PQconninfoParse(const char *conninfo, char **errmsg);
        has been sent to the server and not yet completed.
       </para>
 
-      <caution>
-       <para>
-        <function>PQtransactionStatus</> will give incorrect results when using
-        a <productname>PostgreSQL</> 7.3 server that has the parameter <literal>autocommit</>
-        set to off.  The server-side autocommit feature has been
-        deprecated and does not exist in later server versions.
-       </para>
-      </caution>
      </listitem>
     </varlistentry>
 

doc/src/sgml/protocol.sgml

@@ -1,4 +1,4 @@
-<!-- $PostgreSQL: pgsql/doc/src/sgml/protocol.sgml,v 1.83 2010/02/22 18:12:04 momjian Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/protocol.sgml,v 1.84 2010/02/24 03:33:49 momjian Exp $ -->
 
 <chapter id="protocol">
  <title>Frontend/Backend Protocol</title>
@@ -165,8 +165,8 @@
 
    <para>
     Data of a particular data type might be transmitted in any of several
-    different <firstterm>formats</>.  As of <productname>PostgreSQL</> 7.4
-    the only supported formats are <quote>text</> and <quote>binary</>,
+    different <firstterm>formats</>.
+    The only supported formats are <quote>text</> and <quote>binary</>,
     but the protocol makes provision for future extensions.  The desired
     format for any value is specified by a <firstterm>format code</>.
     Clients can specify a format code for each transmitted parameter value

doc/src/sgml/rules.sgml

@@ -1,4 +1,4 @@
-<!-- $PostgreSQL: pgsql/doc/src/sgml/rules.sgml,v 1.53 2009/11/05 23:24:22 tgl Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/rules.sgml,v 1.54 2010/02/24 03:33:49 momjian Exp $ -->
 
 <chapter id="rules">
 <title>The Rule System</title>
@@ -1828,9 +1828,6 @@ GRANT SELECT ON phone_number TO secretary;
      </listitem>
     </itemizedlist>
 
-    (This system was established in <productname>PostgreSQL</> 7.3.
-    In versions before that, the command status might show different
-    results when rules exist.)
 </para>
 
 <para>

doc/src/sgml/xindex.sgml

@@ -1,4 +1,4 @@
-<!-- $PostgreSQL: pgsql/doc/src/sgml/xindex.sgml,v 1.64 2008/12/07 23:46:39 alvherre Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/xindex.sgml,v 1.65 2010/02/24 03:33:49 momjian Exp $ -->
 
 <sect1 id="xindex">
  <title>Interfacing Extensions To Indexes</title>
@@ -895,16 +895,6 @@ ALTER OPERATOR FAMILY integer_ops USING btree ADD
    try to use these SQL features with the data type.
   </para>
 
-   <note>
-    <para>
-     In <productname>PostgreSQL</productname> versions before 7.4,
-     sorting and grouping operations would implicitly use operators named
-     <literal>=</>, <literal>&lt;</>, and <literal>&gt;</>.  The new
-     behavior of relying on default operator classes avoids having to make
-     any assumption about the behavior of operators with particular names.
-    </para>
-   </note>
-
   <para>
    Another important point is that an operator that
    appears in a hash operator family is a candidate for hash joins,