docs: remove unnecessary references to old PG versions

16 files changed, 27 insertions, 140 deletions

diff --git a/doc/src/sgml/datatype.sgml b/doc/src/sgml/datatype.sgml
index 2319c7d81c..ac285ce011 100644
--- a/doc/src/sgml/datatype.sgml
+++ b/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>
diff --git a/doc/src/sgml/ddl.sgml b/doc/src/sgml/ddl.sgml
index bae2e973e2..8ace8bd3a2 100644
--- a/doc/src/sgml/ddl.sgml
+++ b/doc/src/sgml/ddl.sgml
@@ -1106,9 +1106,8 @@ CREATE TABLE circles (
     within a single transaction.  In practice this limit is not a
     problem &mdash; 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.)
diff --git a/doc/src/sgml/extend.sgml b/doc/src/sgml/extend.sgml
index 367f35b0ab..3ee6ba2f67 100644
--- a/doc/src/sgml/extend.sgml
+++ b/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.
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index a6396620fe..ff50328114 100644
--- a/doc/src/sgml/func.sgml
+++ b/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>
diff --git a/doc/src/sgml/libpq.sgml b/doc/src/sgml/libpq.sgml
index 33641ade60..22815bc9ad 100644
--- a/doc/src/sgml/libpq.sgml
+++ b/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>
 
diff --git a/doc/src/sgml/pgrowlocks.sgml b/doc/src/sgml/pgrowlocks.sgml
index 3e3e57f356..d73511579c 100644
--- a/doc/src/sgml/pgrowlocks.sgml
+++ b/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>
 
diff --git a/doc/src/sgml/plpgsql.sgml b/doc/src/sgml/plpgsql.sgml
index 25e98bdf8e..bddd458528 100644
--- a/doc/src/sgml/plpgsql.sgml
+++ b/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>;
diff --git a/doc/src/sgml/plpython.sgml b/doc/src/sgml/plpython.sgml
index ad89355d60..3f0e6290bb 100644
--- a/doc/src/sgml/plpython.sgml
+++ b/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
diff --git a/doc/src/sgml/ref/create_cast.sgml b/doc/src/sgml/ref/create_cast.sgml
index 2e69a10a8e..11266755e5 100644
--- a/doc/src/sgml/ref/create_cast.sgml
+++ b/doc/src/sgml/ref/create_cast.sgml
@@ -332,17 +332,6 @@ SELECT CAST ( 2 AS numeric ) + 4.0;
   </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
    type.  Many users are used to being able to cast data types using a
diff --git a/doc/src/sgml/ref/create_table_as.sgml b/doc/src/sgml/ref/create_table_as.sgml
index b353a43761..60300ff21e 100644
--- a/doc/src/sgml/ref/create_table_as.sgml
+++ b/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>
 
diff --git a/doc/src/sgml/ref/pg_config-ref.sgml b/doc/src/sgml/ref/pg_config-ref.sgml
index 9f6db9e39b..0210f6389d 100644
--- a/doc/src/sgml/ref/pg_config-ref.sgml
+++ b/doc/src/sgml/ref/pg_config-ref.sgml
@@ -297,15 +297,6 @@
   <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>,
    <option>--sharedir</option>, <option>--sysconfdir</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>
 
 
diff --git a/doc/src/sgml/ref/reindex.sgml b/doc/src/sgml/ref/reindex.sgml
index 54422c3442..3dfaef43f1 100644
--- a/doc/src/sgml/ref/reindex.sgml
+++ b/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>
diff --git a/doc/src/sgml/ref/select_into.sgml b/doc/src/sgml/ref/select_into.sgml
index cf16372528..84b0dd831f 100644
--- a/doc/src/sgml/ref/select_into.sgml
+++ b/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>
diff --git a/doc/src/sgml/rules.sgml b/doc/src/sgml/rules.sgml
index 311fc8b0a1..2686c8f517 100644
--- a/doc/src/sgml/rules.sgml
+++ b/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>
diff --git a/doc/src/sgml/storage.sgml b/doc/src/sgml/storage.sgml
index c587b69047..57e7f095b5 100644
--- a/doc/src/sgml/storage.sgml
+++ b/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">
diff --git a/doc/src/sgml/xfunc.sgml b/doc/src/sgml/xfunc.sgml
index 4fb42842c6..2b4ade0ffb 100644
--- a/doc/src/sgml/xfunc.sgml
+++ b/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