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 <[email protected]> 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. +
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><</>, and <literal>></>. 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 ----
--
Sent via pgsql-docs mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs
