Remove pre-7.4 documentaiton mentions, now that 8.0 is the oldest
authorBruce Momjian
Wed, 24 Feb 2010 03:33:49 +0000 (03:33 +0000)
committerBruce Momjian
Wed, 24 Feb 2010 03:33:49 +0000 (03:33 +0000)
supported release.

doc/src/sgml/datatype.sgml
doc/src/sgml/ddl.sgml
doc/src/sgml/libpq.sgml
doc/src/sgml/protocol.sgml
doc/src/sgml/rules.sgml
doc/src/sgml/xindex.sgml

index 215a4dbab147fd56a8e0bb47be13a03aaacf4f2b..f7c954a58c5831832ae5b67fd7c8e8e05729c52e 100644 (file)
@@ -1,4 +1,4 @@
-
+
 
  
   Data Types
@@ -715,11 +715,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
@@ -795,11 +791,9 @@ 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.
+      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.
      
     
 
@@ -1521,14 +1515,6 @@ SELECT E'\\xDEADBEEF';
      
     
 
-   
-    
-     Prior to PostgreSQL 7.3, writing just
-     timestamp was equivalent to timestamp with
-     time zone.  This was changed for SQL compliance.
-    
-   
-
    
     timetimestamp, and
     interval accept an optional precision value
index 87bec50fd5a491409556e11962e95e9effc17060..39582d166710bf7f6d0f7a56701e06a5c4945cf4 100644 (file)
@@ -1,4 +1,4 @@
-
+
 
 
  Data Definition
@@ -1795,18 +1795,12 @@ 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
-    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 pg_, so that they will not
-    conflict with unqualified user-table names so long as users avoid
-    the pg_ prefix.
+    It is best to avoid table names beginning with pg_
+    because they might someday conflict with system catalogs of the
+    same name.  (PostgreSQL system catalog
+    table names always start with pg_).  Of course, table
+    names can always be schema-qualified to avoid conflicting with
+    system catalog table names.
    
   
 
@@ -3040,15 +3034,6 @@ DROP TABLE products CASCADE;
    
   
 
-  
-   
-    Foreign key constraint dependencies and serial column dependencies
-    from PostgreSQL versions prior to 7.3
-    are not maintained or created during the
-    upgrade process.  All other dependency types will be properly
-    created during an upgrade from a pre-7.3 database.
-   
-  
  
 
 
index 6ab8969fc8b66b6342f0f86e5aba0ff04d1015e9..611f679c4d328ba6b55dcecd0160b69e9b0d1047 100644 (file)
@@ -1,4 +1,4 @@
-
+
 
 
  <application>libpq</application> - C Library
@@ -1203,14 +1203,6 @@ PQconninfoOption *PQconninfoParse(const char *conninfo, char **errmsg);
        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.
-       
-      
      
     
 
index 00711a45e945af9691e72277061e40ebf4b9a3f4..3b1cd38287b198c191fdb67ce1aef09e516c67b4 100644 (file)
@@ -1,4 +1,4 @@
-
+
 
 
  Frontend/Backend Protocol
 
    
     Data of a particular data type might be transmitted in any of several
-    different formats.  As of PostgreSQL 7.4
-    the only supported formats are text and binary,
+    different formats.
+    The only supported formats are text and binary,
     but the protocol makes provision for future extensions.  The desired
     format for any value is specified by a format code.
     Clients can specify a format code for each transmitted parameter value
index bba363fedc3ca68032061e8f20920f2551e24932..44071ce743cd634e3e3bacbf1842b6a4e5fc8ab5 100644 (file)
@@ -1,4 +1,4 @@
-
+
 
 
 The Rule System
@@ -1828,9 +1828,6 @@ GRANT SELECT ON phone_number TO secretary;
      
     
 
-    (This system was established in PostgreSQL 7.3.
-    In versions before that, the command status might show different
-    results when rules exist.)
 
 
 
index 485b6c06a1e5f1085314f575be2d2b89994d2513..fa9fecf5ba3a26c29b8299ae104b83eadd128767 100644 (file)
@@ -1,4 +1,4 @@
-
+
 
 
  Interfacing Extensions To Indexes
@@ -895,16 +895,6 @@ ALTER OPERATOR FAMILY integer_ops USING btree ADD
    try to use these SQL features with the data type.
   
 
-   
-    
-     In PostgreSQL versions before 7.4,
-     sorting and grouping operations would implicitly use operators named
-     =, <, and >.  The new
-     behavior of relying on default operator classes avoids having to make
-     any assumption about the behavior of operators with particular names.
-    
-   
-
   
    Another important point is that an operator that
    appears in a hash operator family is a candidate for hash joins,