docs: remove unnecessary references to old PG versions

doc/src/sgml/datatype.sgml

@@ -750,11 +750,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
@@ -850,16 +846,6 @@ ALTER SEQUENCE <replaceable class="parameter">tablename</replaceable>_<replaceab
       </para>
     </note>
 
-    <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.
-     </para>
-    </note>
-
     <para>
      To insert the next value of the sequence into the <type>serial</type>
      column, specify that the <type>serial</type>
@@ -1611,8 +1597,7 @@ SELECT E'\\xDEADBEEF';
      The SQL standard requires that writing just <type>timestamp</type>
      be equivalent to <type>timestamp without time
      zone</type>, and <productname>PostgreSQL</productname> honors that
-     behavior.  (Releases prior to 7.3 treated it as <type>timestamp
-     with time zone</type>.)  <type>timestamptz</type> is accepted as an
+     behavior.  <type>timestamptz</type> is accepted as an
      abbreviation for <type>timestamp with time zone</type>; this is a
      <productname>PostgreSQL</productname> extension.
     </para>

doc/src/sgml/ddl.sgml

@@ -1106,9 +1106,8 @@ CREATE TABLE circles (
     within a single transaction.  In practice this limit is not a
     problem — note that the limit is on the number of
     <acronym>SQL</acronym> commands, not the number of rows processed.
-    Also, as of <productname>PostgreSQL</productname> 8.3, only commands
-    that actually modify the database contents will consume a command
-    identifier.
+    Also, only commands that actually modify the database contents will
+    consume a command identifier.
    </para>
  </sect1>
 
@@ -1873,11 +1872,8 @@ 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
+    Since system table names begin with <literal>pg_</>, it is best 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.)

doc/src/sgml/extend.sgml

@@ -1161,16 +1161,6 @@ include $(PGXS)
     or on the <literal>make</literal> command line.
    </para>
 
-   <caution>
-    <para>
-     Changing <varname>PG_CONFIG</varname> only works when building
-     against <productname>PostgreSQL</productname> 8.3 or later.
-     With older releases it does not work to set it to anything except
-     <literal>pg_config</>; you must alter your <varname>PATH</>
-     to select the installation to build against.
-    </para>
-   </caution>
-
    <para>
     You can also run <literal>make</literal> in a directory outside the source
     tree of your extension, if you want to keep the build directory separate.

doc/src/sgml/func.sgml

@@ -3549,11 +3549,9 @@ cast(-44 as bit(12))           <lineannotation>111111010100</lineannotation>
 
     <note>
      <para>
-      Prior to <productname>PostgreSQL</productname> 8.0, casting an
-      integer to <type>bit(n)</> would copy the leftmost <literal>n</>
-      bits of the integer, whereas now it copies the rightmost <literal>n</>
-      bits.  Also, casting an integer to a bit string width wider than
-      the integer itself will sign-extend on the left.
+      Casting an integer to <type>bit(n)</> copies the rightmost
+      <literal>n</> bits.  Casting an integer to a bit string width wider
+      than the integer itself will sign-extend on the left.
      </para>
     </note>
 
@@ -6959,12 +6957,6 @@ SELECT EXTRACT(CENTURY FROM TIMESTAMP '2001-02-16 20:38:40');
         If you disagree with this, please write your complaint to:
         Pope, Cathedral Saint-Peter of Roma, Vatican.
        </para>
-
-       <para>
-        <productname>PostgreSQL</productname> releases before 8.0 did not
-        follow the conventional numbering of centuries, but just returned
-        the year field divided by 100.
-       </para>
       </listitem>
      </varlistentry>
 
@@ -7160,12 +7152,6 @@ SELECT EXTRACT(MILLENNIUM FROM TIMESTAMP '2001-02-16 20:38:40');
         Years in the 1900s are in the second millennium.
         The third millennium started January 1, 2001.
        </para>
-
-       <para>
-        <productname>PostgreSQL</productname> releases before 8.0 did not
-        follow the conventional numbering of millennia, but just returned
-        the year field divided by 1000.
-       </para>
       </listitem>
      </varlistentry>
 
@@ -10747,8 +10733,7 @@ nextval('foo'::text)      <lineannotation><literal>foo</literal> is looked up at
         next <function>nextval</function> will return exactly the specified
         value, and sequence advancement commences with the following
         <function>nextval</function>.  Furthermore, the value reported by
-        <function>currval</> is not changed in this case (this is a change
-        from pre-8.3 behavior).  For example,
+        <function>currval</> is not changed in this case.  For example,
 
 <screen>
 SELECT setval('foo', 42);           <lineannotation>Next <function>nextval</> will return 43</lineannotation>

doc/src/sgml/libpq.sgml

@@ -1611,15 +1611,6 @@ PGTransactionStatusType PQtransactionStatus(const PGconn *conn);
        <literal>PQTRANS_ACTIVE</literal> is reported only when a query
        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/pgrowlocks.sgml

@@ -113,8 +113,7 @@ SELECT * FROM accounts AS a, pgrowlocks('accounts') AS p
   WHERE p.locked_row = a.ctid;
 </programlisting>
 
-   Be aware however that (as of <productname>PostgreSQL</> 8.3) such a
-   query will be very inefficient.
+   Be aware however that such a query will be very inefficient.
   </para>
  </sect2>
 

doc/src/sgml/plpgsql.sgml

@@ -388,9 +388,8 @@ BEGIN
 END;
 $$ LANGUAGE plpgsql;
 </programlisting>
-      The other way, which was the only way available before
-      <productname>PostgreSQL</productname> 8.0, is to explicitly
-      declare an alias, using the declaration syntax
+      The other way is to explicitly declare an alias, using the
+      declaration syntax
 
 <synopsis>
 <replaceable>name</replaceable> ALIAS FOR $<replaceable>n</replaceable>;

doc/src/sgml/plpython.sgml

@@ -27,12 +27,11 @@
   </tip>
 
  <para>
-  As of <productname>PostgreSQL</productname> 7.4, PL/Python is only
-  available as an <quote>untrusted</> language, meaning it does not
-  offer any way of restricting what users can do in it.  It has
-  therefore been renamed to <literal>plpythonu</>.  The trusted
-  variant <literal>plpython</> might become available again in future,
-  if a new secure execution mechanism is developed in Python.  The
+  PL/Python is only available as an <quote>untrusted</> language, meaning
+  it does not offer any way of restricting what users can do in it and
+  is therefore named <literal>plpythonu</>.  A trusted
+  variant <literal>plpython</> might become available in the future
+  if a secure execution mechanism is developed in Python.  The
   writer of a function in untrusted PL/Python must take care that the
   function cannot be used to do anything unwanted, since it will be
   able to do anything that could be done by a user logged in as the

doc/src/sgml/ref/create_cast.sgml

@@ -331,17 +331,6 @@ SELECT CAST ( 2 AS numeric ) + 4.0;
    mostly because of requirements of the SQL standard.)
   </para>
 
-  <para>
-   Prior to <productname>PostgreSQL</> 7.3, every function that had
-   the same name as a data type, returned that data type, and took one
-   argument of a different type was automatically a cast function.
-   This convention has been abandoned in face of the introduction of
-   schemas and to be able to represent binary-coercible casts in the
-   system catalogs.  The built-in cast functions still follow this naming
-   scheme, but they have to be shown as casts in the system catalog
-   <structname>pg_cast</> as well.
-  </para>
-
   <para>
    While not required, it is recommended that you continue to follow this old
    convention of naming cast implementation functions after the target data

doc/src/sgml/ref/create_table_as.sgml

@@ -236,19 +236,11 @@ CREATE [ [ GLOBAL | LOCAL ] { TEMPORARY | TEMP } | UNLOGGED ] TABLE <replaceable
   </para>
 
   <para>
-   Prior to <productname>PostgreSQL</productname> 8.0, <command>CREATE
-   TABLE AS</command> always included OIDs in the table it
-   created.  As of <productname>PostgreSQL</productname> 8.0,
-   the <command>CREATE TABLE AS</command> command allows the user to
+   The <command>CREATE TABLE AS</command> command allows the user to
    explicitly specify whether OIDs should be included. If the
    presence of OIDs is not explicitly specified,
    the <xref linkend="guc-default-with-oids"> configuration variable is
-   used.  As of <productname>PostgreSQL</productname> 8.1,
-   this variable is false by default, so the default behavior is not
-   identical to pre-8.0 releases.  Applications that
-   require OIDs in the table created by <command>CREATE TABLE
-   AS</command> should explicitly specify <literal>WITH (OIDS)</literal>
-   to ensure desired behavior.
+   used.
   </para>
  </refsect1>
 

doc/src/sgml/ref/pg_config-ref.sgml

@@ -296,15 +296,6 @@
  <refsect1>
   <title>Notes</title>
 
-  <para>
-   The option <option>--includedir-server</option> was added in
-   <productname>PostgreSQL</> 7.2.  In prior releases, the server include files were
-   installed in the same location as the client headers, which could
-   be queried with the option <option>--includedir</option>.  To make your
-   package handle both cases, try the newer option first and test the
-   exit status to see whether it succeeded.
-  </para>
-
   <para>
    The options <option>--docdir</option>, <option>--pkgincludedir</option>,
    <option>--localedir</option>, <option>--mandir</option>,
@@ -316,12 +307,6 @@
    The option <option>--htmldir</option> was added in <productname>PostgreSQL</> 8.4.
    The option <option>--ldflags_ex</option> was added in <productname>PostgreSQL</> 9.0.
   </para>
-
-  <para>
-   In releases prior to <productname>PostgreSQL</> 7.1, before
-   <command>pg_config</command> came to be, a method for finding the
-   equivalent configuration information did not exist.
-  </para>
  </refsect1>
 
 

doc/src/sgml/ref/reindex.sgml

@@ -218,19 +218,6 @@ REINDEX { INDEX | TABLE | DATABASE | SYSTEM } <replaceable class="PARAMETER">nam
    reindex anything.
   </para>
 
-  <para>
-   Prior to <productname>PostgreSQL</productname> 8.1, <command>REINDEX
-   DATABASE</> processed only system indexes, not all indexes as one would
-   expect from the name.  This has been changed to reduce the surprise
-   factor.  The old behavior is available as <command>REINDEX SYSTEM</>.
-  </para>
-
-  <para>
-   Prior to <productname>PostgreSQL</productname> 7.4, <command>REINDEX
-   TABLE</> did not automatically process TOAST tables, and so those had
-   to be reindexed by separate commands.  This is still possible, but
-   redundant.
-  </para>
  </refsect1>
 
  <refsect1>

doc/src/sgml/ref/select_into.sgml

@@ -106,12 +106,9 @@ SELECT [ ALL | DISTINCT [ ON ( <replaceable class="parameter">expression</replac
   </para>
 
   <para>
-   Prior to <productname>PostgreSQL</> 8.1, the table created by
-   <command>SELECT INTO</command> included OIDs by default. In
-   <productname>PostgreSQL</productname> 8.1, this is not the case
-   &mdash; to include OIDs in the new table, the <xref
-   linkend="guc-default-with-oids"> configuration variable must be
-   enabled. Alternatively, <command>CREATE TABLE AS</command> can be
+   To add OIDs to the table created by <command>SELECT INTO</command>,
+   enable the <xref linkend="guc-default-with-oids"> configuration
+   variable.  Alternatively, <command>CREATE TABLE AS</command> can be
    used with the <literal>WITH OIDS</literal> clause.
   </para>
  </refsect1>

doc/src/sgml/rules.sgml

@@ -2191,10 +2191,6 @@ CREATE VIEW phone_number WITH (security_barrier) AS
       </para>
      </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/storage.sgml

@@ -33,8 +33,7 @@ files, as shown in <xref linkend="pgdata-contents-table">.  In addition to
 these required items, the cluster configuration files
 <filename>postgresql.conf</filename>, <filename>pg_hba.conf</filename>, and
 <filename>pg_ident.conf</filename> are traditionally stored in
-<varname>PGDATA</> (although in <productname>PostgreSQL</productname> 8.0 and
-later, it is possible to place them elsewhere).
+<varname>PGDATA</>, although it is possible to place them elsewhere.
 </para>
 
 <table tocentry="1" id="pgdata-contents-table">

doc/src/sgml/xfunc.sgml

@@ -1465,11 +1465,9 @@ CREATE FUNCTION test(int, int) RETURNS int
 
    <note>
     <para>
-     Before <productname>PostgreSQL</productname> release 8.0, the requirement
-     that <literal>STABLE</> and <literal>IMMUTABLE</> functions cannot modify
-     the database was not enforced by the system.  Releases 8.0 and later enforce it
-     by requiring SQL functions and procedural language functions of these
-     categories to contain no SQL commands other than <command>SELECT</>.
+     <productname>PostgreSQL</productname> requires that <literal>STABLE</>
+     and <literal>IMMUTABLE</> functions contain no SQL commands other
+     than <command>SELECT</> to prevent data modification.
      (This is not a completely bulletproof test, since such functions could
      still call <literal>VOLATILE</> functions that modify the database.
      If you do that, you will find that the <literal>STABLE</> or