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
- Prior to PostgreSQL 7.4, the precision in
- float(p) was taken to mean
- so many decimal> digits. This has been corrected to match the SQL
- standard, which specifies that the precision is measured in binary
- digits. The assumption that real and
+ The assumption that real and
double precision 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 tablename_
-
-
- Prior to PostgreSQL 7.3, serial
- implied UNIQUE. 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.
-
-
-
To insert the next value of the sequence into the serial
column, specify that the serial
@@ -1611,8 +1597,7 @@ SELECT E'\\xDEADBEEF';
The SQL standard requires that writing just timestamp
be equivalent to timestamp without time
zone, and PostgreSQL honors that
- behavior. (Releases prior to 7.3 treated it as timestamp
- with time zone.) timestamptz is accepted as an
+ behavior. timestamptz is accepted as an
abbreviation for timestamp with time zone; this is a
PostgreSQL extension.
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 — note that the limit is on the number of
SQL commands, not the number of rows processed.
- Also, as of PostgreSQL 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.
@@ -1873,11 +1872,8 @@ REVOKE CREATE ON SCHEMA public FROM PUBLIC;
- In PostgreSQL versions before 7.3,
- table names beginning with 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 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 make command line.
-
-
- Changing PG_CONFIG only works when building
- against PostgreSQL 8.3 or later.
- With older releases it does not work to set it to anything except
- pg_config>; you must alter your PATH>
- to select the installation to build against.
-
-
-
You can also run make 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)) 111111010100
- Prior to PostgreSQL 8.0, casting an
- integer to bit(n)> would copy the leftmost n>
- bits of the integer, whereas now it copies the rightmost 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 bit(n)> copies the rightmost
+ n> bits. Casting an integer to a bit string width wider
+ than the integer itself will sign-extend on the left.
@@ -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.
-
-
- PostgreSQL releases before 8.0 did not
- follow the conventional numbering of centuries, but just returned
- the year field divided by 100.
-
@@ -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.
-
-
- PostgreSQL releases before 8.0 did not
- follow the conventional numbering of millennia, but just returned
- the year field divided by 1000.
-
@@ -10747,8 +10733,7 @@ nextval('foo'::text) foo is looked up at
next nextval will return exactly the specified
value, and sequence advancement commences with the following
nextval. Furthermore, the value reported by
- currval> is not changed in this case (this is a change
- from pre-8.3 behavior). For example,
+ currval> is not changed in this case. For example,
SELECT setval('foo', 42); Next nextval> will return 43
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);
PQTRANS_ACTIVE is reported only when a query
has been sent to the server and not yet completed.
-
-
-
- PQtransactionStatus> will give incorrect results when using
- a PostgreSQL> 7.3 server that has the parameter autocommit>
- set to off. The server-side autocommit feature has been
- deprecated and does not exist in later server versions.
-
-
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;
- Be aware however that (as of PostgreSQL> 8.3) such a
- query will be very inefficient.
+ Be aware however that such a query will be very inefficient.
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;
- The other way, which was the only way available before
- PostgreSQL 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
name ALIAS FOR $n;
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 @@
- As of PostgreSQL 7.4, PL/Python is only
- available as an untrusted> language, meaning it does not
- offer any way of restricting what users can do in it. It has
- therefore been renamed to plpythonu>. The trusted
- variant 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 untrusted> language, meaning
+ it does not offer any way of restricting what users can do in it and
+ is therefore named plpythonu>. A trusted
+ variant 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
@@ -331,17 +331,6 @@ SELECT CAST ( 2 AS numeric ) + 4.0;
mostly because of requirements of the SQL standard.)
-
- Prior to 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
- pg_cast> as well.
-
-
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 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
- Prior to PostgreSQL 8.0, CREATE
- TABLE AS always included OIDs in the table it
- created. As of PostgreSQL 8.0,
- the CREATE TABLE AS command allows the user to
+ The CREATE TABLE AS command allows the user to
explicitly specify whether OIDs should be included. If the
presence of OIDs is not explicitly specified,
the configuration variable is
- used. As of PostgreSQL 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 CREATE TABLE
- AS should explicitly specify WITH (OIDS)
- to ensure desired behavior.
+ used.
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
@@ -296,15 +296,6 @@
Notes
-
- The option was added in
- 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 . To make your
- package handle both cases, try the newer option first and test the
- exit status to see whether it succeeded.
-
-
The options , ,
, ,
@@ -316,12 +307,6 @@
The option was added in PostgreSQL> 8.4.
The option was added in PostgreSQL> 9.0.
-
-
- In releases prior to PostgreSQL> 7.1, before
- pg_config came to be, a method for finding the
- equivalent configuration information did not exist.
-
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 } nam
reindex anything.
-
- Prior to PostgreSQL 8.1, 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 REINDEX SYSTEM>.
-
-
-
- Prior to PostgreSQL 7.4, REINDEX
- TABLE> did not automatically process TOAST tables, and so those had
- to be reindexed by separate commands. This is still possible, but
- redundant.
-
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 ( expression
- Prior to PostgreSQL> 8.1, the table created by
- SELECT INTO included OIDs by default. In
- PostgreSQL 8.1, this is not the case
- — to include OIDs in the new table, the configuration variable must be
- enabled. Alternatively, CREATE TABLE AS can be
+ To add OIDs to the table created by SELECT INTO,
+ enable the configuration
+ variable. Alternatively, CREATE TABLE AS can be
used with the WITH OIDS clause.
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
-
- (This system was established in PostgreSQL> 7.3.
- In versions before that, the command status might show different
- results when rules exist.)
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 . In addition to
these required items, the cluster configuration files
postgresql.conf, pg_hba.conf, and
pg_ident.conf are traditionally stored in
-PGDATA> (although in PostgreSQL 8.0 and
-later, it is possible to place them elsewhere).
+PGDATA>, although it is possible to place them elsewhere.
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
- Before PostgreSQL release 8.0, the requirement
- that STABLE> and 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 SELECT>.
+ PostgreSQL requires that STABLE>
+ and IMMUTABLE> functions contain no SQL commands other
+ than SELECT> to prevent data modification.
(This is not a completely bulletproof test, since such functions could
still call VOLATILE> functions that modify the database.
If you do that, you will find that the STABLE> or