mirror of
https://git.postgresql.org/git/postgresql.git
synced 2024-12-21 08:29:39 +08:00
docs: remove unnecessary references to old PG versions
This commit is contained in:
parent
4bad548d98
commit
6f14a6f703
@ -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>
|
||||
|
@ -1106,9 +1106,8 @@ CREATE TABLE circles (
|
||||
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.
|
||||
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.)
|
||||
|
@ -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.
|
||||
|
@ -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>
|
||||
|
@ -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>
|
||||
|
||||
|
@ -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>
|
||||
|
||||
|
@ -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>;
|
||||
|
@ -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
|
||||
|
@ -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
|
||||
|
@ -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>
|
||||
|
||||
|
@ -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>
|
||||
|
||||
|
||||
|
@ -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>
|
||||
|
@ -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
|
||||
— 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>
|
||||
|
@ -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>
|
||||
|
@ -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">
|
||||
|
@ -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
|
||||
|
Loading…
Reference in New Issue
Block a user