diff --git a/doc/src/sgml/datatype.sgml b/doc/src/sgml/datatype.sgml
index 2319c7d81cb6dace03c7f2c478d6a00bdf98860e..ac285ce01190e30455dd53022ab110b64e765ca5 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 bae2e973e2b1a558a9502f1e5215a607bf539b81..8ace8bd3a2537849cdaac52b620baa8ed97a9095 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 — 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 367f35b0abcde4b705b33c97ed94446a8f06a1c1..3ee6ba2f6794846ff66a8961c5255f95719767e7 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 a6396620fe736a41ad726da8011eebf2ca60a7c8..ff503281140b87669d959fa4eddd40920b5fbe86 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 33641ade60867ecf6813e4c63a4378597a038b0f..22815bc9ad8e54f09d3ed120d58f24d2c5fe8fd2 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 3e3e57f356a7ccb140bf66f14a1ea52263164b09..d73511579c43c066362658f180e4bf4c0bc65896 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 25e98bdf8ea12400685788b7f362bbead656b23a..bddd4585283af6510dc52d1d384b7b0d7373e816 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 ad89355d60d5741e7ab9a9d456bee24b9a741eae..3f0e6290bb2325a3534f22cb84cf3aacda5efcf1 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 2e69a10a8ef2d30d8299c345a4da6acc94a75712..11266755e56ea9f9537a2abd52a520731e388684 100644
--- a/doc/src/sgml/ref/create_cast.sgml
+++ b/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
diff --git a/doc/src/sgml/ref/create_table_as.sgml b/doc/src/sgml/ref/create_table_as.sgml
index b353a43761307530de1c5665c1a6737609a28d0f..60300ff21e9d3fe027aa2b15012390b5ea5096bc 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 9f6db9e39b4e60bf18ee039520846f23f6dee2af..0210f6389dc6078f423d7633acfd45a13853879b 100644
--- a/doc/src/sgml/ref/pg_config-ref.sgml
+++ b/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>
diff --git a/doc/src/sgml/ref/reindex.sgml b/doc/src/sgml/ref/reindex.sgml
index 54422c3442cc612bb9f5eee2ccd3624285321956..3dfaef43f1fde14d2d4cd48d06f88fd483c13e34 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 cf163725288ffebdf5b4babe33acff806558b040..84b0dd831f915624165bd4f5baa6804ee475d70b 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
- — 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 311fc8b0a1851e4f504c09c3036868abf6d685a5..2686c8f517865b950dcb9e378a0eac362a72b467 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 c587b690474f5fccb55c895b403562383b3c5cd7..57e7f095b50820ee65179dd4c506a45152cc51a1 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 4fb42842c6f88d1e77f8fd4b3cea475194c67e45..2b4ade0ffb315e72077bec3ff0e7a2195c57fb19 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