On Mon, Oct 7, 2013 at 08:43:27AM -0700, David Fetter wrote:
> On Mon, Oct 07, 2013 at 07:51:44AM -0400, Andrew Dunstan wrote:
> >
> > Given that we have not supported releases older than 8.3 for quite a
> > while, do we need to keep this in extend.sgml any longer?
> >
> > <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>
>
> I say "bin it." That reminds me. There are probably a lot of places
> in the docs that refer to versions of PostgreSQL a good bit older than
> 8.3. Will grep and patch as I get the time.
I have created the attached patch which removes many of the pre-8.0
references, and trims some of the 8.1-8.3 references. There are
probably some of these that should be kept, but it is easier to show you
all the possibilities and we can trim down the removal list based on
feedback.
--
Bruce Momjian <br...@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
diff --git a/doc/src/sgml/datatype.sgml b/doc/src/sgml/datatype.sgml
new file mode 100644
index 30fd9bb..a5b74e6
*** a/doc/src/sgml/datatype.sgml
--- b/doc/src/sgml/datatype.sgml
*************** NUMERIC
*** 744,754 ****
<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
--- 744,750 ----
<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
*************** ALTER SEQUENCE <replaceable class="param
*** 844,859 ****
</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>
--- 840,845 ----
*************** SELECT E'\\xDEADBEEF';
*** 1602,1609 ****
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
abbreviation for <type>timestamp with time zone</type>; this is a
<productname>PostgreSQL</productname> extension.
</para>
--- 1588,1594 ----
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. <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
new file mode 100644
index bae2e97..8ace8bd
*** a/doc/src/sgml/ddl.sgml
--- b/doc/src/sgml/ddl.sgml
*************** CREATE TABLE circles (
*** 1106,1114 ****
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.
</para>
</sect1>
--- 1106,1113 ----
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, only commands that actually modify the database contents will
! consume a command identifier.
</para>
</sect1>
*************** REVOKE CREATE ON SCHEMA public FROM PUBL
*** 1873,1883 ****
</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.)
--- 1872,1879 ----
</para>
<para>
! 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
new file mode 100644
index 367f35b..3ee6ba2
*** a/doc/src/sgml/extend.sgml
--- b/doc/src/sgml/extend.sgml
*************** include $(PGXS)
*** 1161,1176 ****
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.
--- 1161,1166 ----
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
new file mode 100644
index be548d7..9bab32b
*** a/doc/src/sgml/func.sgml
--- b/doc/src/sgml/func.sgml
*************** cast(-44 as bit(12)) <lineanno
*** 3549,3559 ****
<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.
</para>
</note>
--- 3549,3557 ----
<note>
<para>
! 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>
*************** SELECT EXTRACT(CENTURY FROM TIMESTAMP '2
*** 6959,6970 ****
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>
--- 6957,6962 ----
*************** SELECT EXTRACT(MILLENNIUM FROM TIMESTAMP
*** 7160,7171 ****
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>
--- 7152,7157 ----
*************** nextval('foo'::text) <lineannotatio
*** 10747,10754 ****
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,
<screen>
SELECT setval('foo', 42); <lineannotation>Next <function>nextval</> will return 43</lineannotation>
--- 10733,10739 ----
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. 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
new file mode 100644
index 33641ad..22815bc
*** a/doc/src/sgml/libpq.sgml
--- b/doc/src/sgml/libpq.sgml
*************** PGTransactionStatusType PQtransactionSta
*** 1611,1625 ****
<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>
--- 1611,1616 ----
diff --git a/doc/src/sgml/lobj.sgml b/doc/src/sgml/lobj.sgml
new file mode 100644
index d403586..3d5ce3e
*** a/doc/src/sgml/lobj.sgml
--- b/doc/src/sgml/lobj.sgml
*************** Oid lo_create(PGconn *conn, Oid lobjId);
*** 176,182 ****
</para>
<para>
! <function>lo_create</> is new as of <productname>PostgreSQL</productname>
8.1; if this function is run against an older server version, it will
fail and return <symbol>InvalidOid</symbol>.
</para>
--- 176,182 ----
</para>
<para>
! <function>lo_create</> was added in <productname>PostgreSQL</productname>
8.1; if this function is run against an older server version, it will
fail and return <symbol>InvalidOid</symbol>.
</para>
*************** Oid lo_import_with_oid(PGconn *conn, con
*** 226,232 ****
<para>
<function>lo_import_with_oid</> is new as of <productname>PostgreSQL</productname>
! 8.4 and uses <function>lo_create</function> internally which is new in 8.1; if this function is run against 8.0 or before, it will
fail and return <symbol>InvalidOid</symbol>.
</para>
</sect2>
--- 226,233 ----
<para>
<function>lo_import_with_oid</> is new as of <productname>PostgreSQL</productname>
! 8.4 and uses <function>lo_create</function> internally which was
! added in 8.1; if this function is run against 8.0 or before, it will
fail and return <symbol>InvalidOid</symbol>.
</para>
</sect2>
*************** int lo_truncate64(PGcon *conn, int fd, p
*** 473,479 ****
</para>
<para>
! <function>lo_truncate</> is new as of <productname>PostgreSQL</productname>
8.3; if this function is run against an older server version, it will
fail and return -1.
</para>
--- 474,480 ----
</para>
<para>
! <function>lo_truncate</> was added in <productname>PostgreSQL</productname>
8.3; if this function is run against an older server version, it will
fail and return -1.
</para>
diff --git a/doc/src/sgml/pgrowlocks.sgml b/doc/src/sgml/pgrowlocks.sgml
new file mode 100644
index 3e3e57f..d735115
*** a/doc/src/sgml/pgrowlocks.sgml
--- b/doc/src/sgml/pgrowlocks.sgml
*************** SELECT * FROM accounts AS a, pgrowlocks(
*** 113,120 ****
WHERE p.locked_row = a.ctid;
</programlisting>
! Be aware however that (as of <productname>PostgreSQL</> 8.3) such a
! query will be very inefficient.
</para>
</sect2>
--- 113,119 ----
WHERE p.locked_row = a.ctid;
</programlisting>
! 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
new file mode 100644
index 25e98bd..bddd458
*** a/doc/src/sgml/plpgsql.sgml
--- b/doc/src/sgml/plpgsql.sgml
*************** BEGIN
*** 388,396 ****
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
<synopsis>
<replaceable>name</replaceable> ALIAS FOR $<replaceable>n</replaceable>;
--- 388,395 ----
END;
$$ LANGUAGE plpgsql;
</programlisting>
! 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
new file mode 100644
index ad89355..3f0e629
*** a/doc/src/sgml/plpython.sgml
--- b/doc/src/sgml/plpython.sgml
***************
*** 27,38 ****
</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
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
--- 27,37 ----
</tip>
<para>
! 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
new file mode 100644
index 29ea298..822f2f8
*** a/doc/src/sgml/ref/create_cast.sgml
--- b/doc/src/sgml/ref/create_cast.sgml
*************** SELECT CAST ( 2 AS numeric ) + 4.0;
*** 332,348 ****
</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
type. Many users are used to being able to cast data types using a
--- 332,337 ----
diff --git a/doc/src/sgml/ref/create_table_as.sgml b/doc/src/sgml/ref/create_table_as.sgml
new file mode 100644
index 29c8040..ed04979
*** a/doc/src/sgml/ref/create_table_as.sgml
--- b/doc/src/sgml/ref/create_table_as.sgml
*************** CREATE [ [ GLOBAL | LOCAL ] { TEMPORARY
*** 236,254 ****
</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
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.
</para>
</refsect1>
--- 236,246 ----
</para>
<para>
! 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.
</para>
</refsect1>
diff --git a/doc/src/sgml/ref/pg_config-ref.sgml b/doc/src/sgml/ref/pg_config-ref.sgml
new file mode 100644
index 5aac38b..e3f6732
*** a/doc/src/sgml/ref/pg_config-ref.sgml
--- b/doc/src/sgml/ref/pg_config-ref.sgml
***************
*** 297,311 ****
<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>,
<option>--sharedir</option>, <option>--sysconfdir</option>,
--- 297,302 ----
***************
*** 316,327 ****
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>
--- 307,312 ----
diff --git a/doc/src/sgml/ref/reindex.sgml b/doc/src/sgml/ref/reindex.sgml
new file mode 100644
index 7222665..736b758
*** a/doc/src/sgml/ref/reindex.sgml
--- b/doc/src/sgml/ref/reindex.sgml
*************** REINDEX { INDEX | TABLE | DATABASE | SYS
*** 218,236 ****
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>
--- 218,223 ----
diff --git a/doc/src/sgml/ref/select_into.sgml b/doc/src/sgml/ref/select_into.sgml
new file mode 100644
index 48b789b..e6b5861
*** a/doc/src/sgml/ref/select_into.sgml
--- b/doc/src/sgml/ref/select_into.sgml
*************** SELECT [ ALL | DISTINCT [ ON ( <replacea
*** 106,117 ****
</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
used with the <literal>WITH OIDS</literal> clause.
</para>
</refsect1>
--- 106,114 ----
</para>
<para>
! 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
new file mode 100644
index 311fc8b..2686c8f
*** a/doc/src/sgml/rules.sgml
--- b/doc/src/sgml/rules.sgml
*************** CREATE VIEW phone_number WITH (security_
*** 2191,2200 ****
</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>
--- 2191,2196 ----
diff --git a/doc/src/sgml/storage.sgml b/doc/src/sgml/storage.sgml
new file mode 100644
index 1f3f1f9..d0894ce
*** a/doc/src/sgml/storage.sgml
--- b/doc/src/sgml/storage.sgml
*************** files, as shown in <xref linkend="pgdata
*** 33,40 ****
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).
</para>
<table tocentry="1" id="pgdata-contents-table">
--- 33,39 ----
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 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
new file mode 100644
index 4fb4284..2b4ade0
*** a/doc/src/sgml/xfunc.sgml
--- b/doc/src/sgml/xfunc.sgml
*************** CREATE FUNCTION test(int, int) RETURNS i
*** 1465,1475 ****
<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</>.
(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
--- 1465,1473 ----
<note>
<para>
! <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
diff --git a/doc/src/sgml/xindex.sgml b/doc/src/sgml/xindex.sgml
new file mode 100644
index 806b358..1373e35
*** a/doc/src/sgml/xindex.sgml
--- b/doc/src/sgml/xindex.sgml
*************** ALTER OPERATOR FAMILY integer_ops USING
*** 1034,1049 ****
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,
--- 1034,1039 ----
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
