Received: from maia.hub.org (unknown [200.46.204.183])
	by mail.postgresql.org (Postfix) with ESMTP id A3D7F632CBB
	for <pgsql-docs-postgresql.org@mail.postgresql.org>;
	Mon, 22 Feb 2010 20:18:30 -0400 (AST)
Received: from mail.postgresql.org ([200.46.204.86])
	by maia.hub.org (mx1.hub.org [200.46.204.183]) (amavisd-maia,
	port 10024) with ESMTP id 69090-08 for
	<pgsql-docs-postgresql.org@mail.postgresql.org>;
	Tue, 23 Feb 2010 00:18:19 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from momjian.us (momjian.us [70.90.9.53])
	by mail.postgresql.org (Postfix) with ESMTP id 0C037632B36
	for <pgsql-docs@postgresql.org>; Mon, 22 Feb 2010 20:18:19 -0400 (AST)
Received: (from bruce@localhost) by momjian.us (8.11.6/8.11.6) id o1N0IIL15944
	for pgsql-docs@postgresql.org; Mon, 22 Feb 2010 19:18:18 -0500 (EST)
From: Bruce Momjian <bruce@momjian.us>
Message-Id: <201002230018.o1N0IIL15944@momjian.us>
Subject: Removal of pre-7.4 documentation items
To: PostgreSQL-documentation <pgsql-docs@postgresql.org>
Date: Mon, 22 Feb 2010 19:18:18 -0500 (EST)
X-Mailer: ELM [version 2.4ME+ PL124 (25)]
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="ELM1266884298-1192-0_"
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Spam-Status: No, hits=-2.599 tagged_above=-10 required=5
	tests=BAYES_00=-2.599
X-Spam-Level: 
X-Archive-Number: 201002/17
X-Sequence-Number: 5333


--ELM1266884298-1192-0_
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"

With us supporting only PG >=8.0, I think we can remove some mentions of
pre-7.4 releases.  The attached patch show my proposed removals.

-- 
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com
  PG East:  http://www.enterprisedb.com/community/nav-pg-east-2010.do
  + If your life is a hard drive, Christ can be your backup. +

--ELM1266884298-1192-0_
Content-Transfer-Encoding: 7bit
Content-Type: text/x-diff
Content-Disposition: inline; filename="/pgpatches/backver-doc"

Index: doc/src/sgml/datatype.sgml
===================================================================
RCS file: /cvsroot/pgsql/doc/src/sgml/datatype.sgml,v
retrieving revision 1.242
diff -c -c -r1.242 datatype.sgml
*** doc/src/sgml/datatype.sgml	17 Feb 2010 04:19:37 -0000	1.242
--- doc/src/sgml/datatype.sgml	23 Feb 2010 00:16:14 -0000
***************
*** 715,725 ****
  
      <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
        <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
--- 715,721 ----
  
      <note>
       <para>
!       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
***************
*** 795,805 ****
  
      <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>
  
--- 791,799 ----
  
      <note>
       <para>
!       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.
       </para>
      </note>
  
***************
*** 1521,1534 ****
       </tgroup>
      </table>
  
-    <note>
-     <para>
-      Prior to <productname>PostgreSQL</productname> 7.3, writing just
-      <type>timestamp</type> was equivalent to <type>timestamp with
-      time zone</type>.  This was changed for SQL compliance.
-     </para>
-    </note>
- 
     <para>
      <type>time</type>, <type>timestamp</type>, and
      <type>interval</type> accept an optional precision value
--- 1515,1520 ----
Index: doc/src/sgml/ddl.sgml
===================================================================
RCS file: /cvsroot/pgsql/doc/src/sgml/ddl.sgml,v
retrieving revision 1.88
diff -c -c -r1.88 ddl.sgml
*** doc/src/sgml/ddl.sgml	23 Oct 2009 05:24:52 -0000	1.88
--- doc/src/sgml/ddl.sgml	23 Feb 2010 00:16:14 -0000
***************
*** 1795,1812 ****
     </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
!     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 <literal>pg_</>, so that they will not
!     conflict with unqualified user-table names so long as users avoid
!     the <literal>pg_</> prefix.
     </para>
    </sect2>
  
--- 1795,1806 ----
     </para>
  
     <para>
!     It is best to avoid table names beginning with <literal>pg_</>
!     because they might someday conflict with system catalogs of the
!     same name.  (<productname>PostgreSQL</productname> system catalog
!     table names always start with <literal>pg_</>).  Of course, table
!     names can always be schema-qualified to avoid conflicting with
!     system catalog table names.
     </para>
    </sect2>
  
***************
*** 3040,3054 ****
     </para>
    </note>
  
-   <note>
-    <para>
-     Foreign key constraint dependencies and serial column dependencies
-     from <productname>PostgreSQL</productname> versions prior to 7.3
-     are <emphasis>not</emphasis> maintained or created during the
-     upgrade process.  All other dependency types will be properly
-     created during an upgrade from a pre-7.3 database.
-    </para>
-   </note>
   </sect1>
  
  </chapter>
--- 3034,3039 ----
Index: doc/src/sgml/libpq.sgml
===================================================================
RCS file: /cvsroot/pgsql/doc/src/sgml/libpq.sgml,v
retrieving revision 1.300
diff -c -c -r1.300 libpq.sgml
*** doc/src/sgml/libpq.sgml	17 Feb 2010 04:19:37 -0000	1.300
--- doc/src/sgml/libpq.sgml	23 Feb 2010 00:16:14 -0000
***************
*** 1203,1216 ****
         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>
  
--- 1203,1208 ----
Index: doc/src/sgml/protocol.sgml
===================================================================
RCS file: /cvsroot/pgsql/doc/src/sgml/protocol.sgml,v
retrieving revision 1.83
diff -c -c -r1.83 protocol.sgml
*** doc/src/sgml/protocol.sgml	22 Feb 2010 18:12:04 -0000	1.83
--- doc/src/sgml/protocol.sgml	23 Feb 2010 00:16:15 -0000
***************
*** 165,172 ****
  
     <para>
      Data of a particular data type might be transmitted in any of several
!     different <firstterm>formats</>.  As of <productname>PostgreSQL</> 7.4
!     the only supported formats are <quote>text</> and <quote>binary</>,
      but the protocol makes provision for future extensions.  The desired
      format for any value is specified by a <firstterm>format code</>.
      Clients can specify a format code for each transmitted parameter value
--- 165,172 ----
  
     <para>
      Data of a particular data type might be transmitted in any of several
!     different <firstterm>formats</>.
!     The only supported formats are <quote>text</> and <quote>binary</>,
      but the protocol makes provision for future extensions.  The desired
      format for any value is specified by a <firstterm>format code</>.
      Clients can specify a format code for each transmitted parameter value
Index: doc/src/sgml/rules.sgml
===================================================================
RCS file: /cvsroot/pgsql/doc/src/sgml/rules.sgml,v
retrieving revision 1.53
diff -c -c -r1.53 rules.sgml
*** doc/src/sgml/rules.sgml	5 Nov 2009 23:24:22 -0000	1.53
--- doc/src/sgml/rules.sgml	23 Feb 2010 00:16:15 -0000
***************
*** 1828,1836 ****
       </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>
--- 1828,1833 ----
Index: doc/src/sgml/xindex.sgml
===================================================================
RCS file: /cvsroot/pgsql/doc/src/sgml/xindex.sgml,v
retrieving revision 1.64
diff -c -c -r1.64 xindex.sgml
*** doc/src/sgml/xindex.sgml	7 Dec 2008 23:46:39 -0000	1.64
--- doc/src/sgml/xindex.sgml	23 Feb 2010 00:16:19 -0000
***************
*** 895,910 ****
     try to use these SQL features with the data type.
    </para>
  
-    <note>
-     <para>
-      In <productname>PostgreSQL</productname> versions before 7.4,
-      sorting and grouping operations would implicitly use operators named
-      <literal>=</>, <literal>&lt;</>, and <literal>&gt;</>.  The new
-      behavior of relying on default operator classes avoids having to make
-      any assumption about the behavior of operators with particular names.
-     </para>
-    </note>
- 
    <para>
     Another important point is that an operator that
     appears in a hash operator family is a candidate for hash joins,
--- 895,900 ----

--ELM1266884298-1192-0_--