rdelaage
/
postgresql
mirror of https://git.postgresql.org/git/postgresql.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

docs: remove unnecessary references to old PG versions

This commit is contained in:
Bruce Momjian 2014-02-24 12:56:37 -05:00
parent 4bad548d98
commit 6f14a6f703
16 changed files with 27 additions and 140 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

19
doc/src/sgml/datatype.sgml
View File

@ -750,11 +750,7 @@ NUMERIC
<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
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
@ -850,16 +846,6 @@ ALTER SEQUENCE <replaceable class="parameter">tablename</replaceable>_<replaceab
</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>
@ -1611,8 +1597,7 @@ SELECT E'\\xDEADBEEF';
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
behavior. <type>timestamptz</type> is accepted as an
abbreviation for <type>timestamp with time zone</type>; this is a
<productname>PostgreSQL</productname> extension.
</para>

12
doc/src/sgml/ddl.sgml
View File

@ -1106,9 +1106,8 @@ CREATE TABLE circles (
within a single transaction. In practice this limit is not a
problem &mdash; 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.
Also, only commands that actually modify the database contents will
consume a command identifier.
</para>
</sect1>
@ -1873,11 +1872,8 @@ REVOKE CREATE ON SCHEMA public FROM PUBLIC;
</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
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.)

10
doc/src/sgml/extend.sgml
View File

@ -1161,16 +1161,6 @@ include $(PGXS)
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.

23
doc/src/sgml/func.sgml
View File

@ -3549,11 +3549,9 @@ cast(-44 as bit(12)) <lineannotation>111111010100</lineannotation>
<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.
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>
@ -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.
</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>
@ -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.
</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>
@ -10747,8 +10733,7 @@ nextval('foo'::text) <lineannotation><literal>foo</literal> is looked up at
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,
<function>currval</> is not changed in this case. For example,
<screen>
SELECT setval('foo', 42); <lineannotation>Next <function>nextval</> will return 43</lineannotation>

9
doc/src/sgml/libpq.sgml
View File

@ -1611,15 +1611,6 @@ PGTransactionStatusType PQtransactionStatus(const PGconn *conn);
<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>

3
doc/src/sgml/pgrowlocks.sgml
View File

@ -113,8 +113,7 @@ SELECT * FROM accounts AS a, pgrowlocks('accounts') AS p
WHERE p.locked_row = a.ctid;
</programlisting>
Be aware however that (as of <productname>PostgreSQL</> 8.3) such a
query will be very inefficient.
Be aware however that such a query will be very inefficient.
</para>
</sect2>

5
doc/src/sgml/plpgsql.sgml
View File

@ -388,9 +388,8 @@ BEGIN
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
The other way is to explicitly declare an alias, using the
declaration syntax
<synopsis>
<replaceable>name</replaceable> ALIAS FOR $<replaceable>n</replaceable>;

11
doc/src/sgml/plpython.sgml
View File

@ -27,12 +27,11 @@
</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
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

11
doc/src/sgml/ref/create_cast.sgml
View File

@ -331,17 +331,6 @@ SELECT CAST ( 2 AS numeric ) + 4.0;
mostly because of requirements of the SQL standard.)
</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

12
doc/src/sgml/ref/create_table_as.sgml
View File

@ -236,19 +236,11 @@ CREATE [ [ GLOBAL | LOCAL ] { TEMPORARY | TEMP } | UNLOGGED ] TABLE <replaceable
</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
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.
used.
</para>
</refsect1>

15
doc/src/sgml/ref/pg_config-ref.sgml
View File

@ -296,15 +296,6 @@
<refsect1>
<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>,
@ -316,12 +307,6 @@
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>

13
doc/src/sgml/ref/reindex.sgml
View File

@ -218,19 +218,6 @@ REINDEX { INDEX | TABLE | DATABASE | SYSTEM } <replaceable class="PARAMETER">nam
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>

9
doc/src/sgml/ref/select_into.sgml
View File

@ -106,12 +106,9 @@ SELECT [ ALL | DISTINCT [ ON ( <replaceable class="parameter">expression</replac
</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
&mdash; 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
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>

4
doc/src/sgml/rules.sgml
View File

@ -2191,10 +2191,6 @@ CREATE VIEW phone_number WITH (security_barrier) AS
</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>

3
doc/src/sgml/storage.sgml
View File

@ -33,8 +33,7 @@ files, as shown in <xref linkend="pgdata-contents-table">. In addition to
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).
<varname>PGDATA</>, although it is possible to place them elsewhere.
</para>
<table tocentry="1" id="pgdata-contents-table">

8
doc/src/sgml/xfunc.sgml
View File

@ -1465,11 +1465,9 @@ CREATE FUNCTION test(int, int) RETURNS int
<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</>.
<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