mirror of
https://github.com/postgres/postgres.git
synced 2025-06-10 09:21:54 +03:00
docs: remove unnecessary references to old PG versions
This commit is contained in:
parent
4bad548d98
commit
6f14a6f703
@ -750,11 +750,7 @@ NUMERIC
|
|||||||
|
|
||||||
<note>
|
<note>
|
||||||
<para>
|
<para>
|
||||||
Prior to <productname>PostgreSQL</productname> 7.4, the precision in
|
The assumption that <type>real</type> and
|
||||||
<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
|
<type>double precision</type> have exactly 24 and 53 bits in the
|
||||||
mantissa respectively is correct for IEEE-standard floating point
|
mantissa respectively is correct for IEEE-standard floating point
|
||||||
implementations. On non-IEEE platforms it might be off a little, but
|
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>
|
</para>
|
||||||
</note>
|
</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>
|
<para>
|
||||||
To insert the next value of the sequence into the <type>serial</type>
|
To insert the next value of the sequence into the <type>serial</type>
|
||||||
column, specify that 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>
|
The SQL standard requires that writing just <type>timestamp</type>
|
||||||
be equivalent to <type>timestamp without time
|
be equivalent to <type>timestamp without time
|
||||||
zone</type>, and <productname>PostgreSQL</productname> honors that
|
zone</type>, and <productname>PostgreSQL</productname> honors that
|
||||||
behavior. (Releases prior to 7.3 treated it as <type>timestamp
|
behavior. <type>timestamptz</type> is accepted as an
|
||||||
with time zone</type>.) <type>timestamptz</type> is accepted as an
|
|
||||||
abbreviation for <type>timestamp with time zone</type>; this is a
|
abbreviation for <type>timestamp with time zone</type>; this is a
|
||||||
<productname>PostgreSQL</productname> extension.
|
<productname>PostgreSQL</productname> extension.
|
||||||
</para>
|
</para>
|
||||||
|
@ -1106,9 +1106,8 @@ CREATE TABLE circles (
|
|||||||
within a single transaction. In practice this limit is not a
|
within a single transaction. In practice this limit is not a
|
||||||
problem — note that the limit is on the number of
|
problem — note that the limit is on the number of
|
||||||
<acronym>SQL</acronym> commands, not the number of rows processed.
|
<acronym>SQL</acronym> commands, not the number of rows processed.
|
||||||
Also, as of <productname>PostgreSQL</productname> 8.3, only commands
|
Also, only commands that actually modify the database contents will
|
||||||
that actually modify the database contents will consume a command
|
consume a command identifier.
|
||||||
identifier.
|
|
||||||
</para>
|
</para>
|
||||||
</sect1>
|
</sect1>
|
||||||
|
|
||||||
@ -1873,11 +1872,8 @@ REVOKE CREATE ON SCHEMA public FROM PUBLIC;
|
|||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
In <productname>PostgreSQL</productname> versions before 7.3,
|
Since system table names begin with <literal>pg_</>, it is best to
|
||||||
table names beginning with <literal>pg_</> were reserved. This is
|
avoid such names to ensure that you won't suffer a conflict if some
|
||||||
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
|
future version defines a system table named the same as your
|
||||||
table. (With the default search path, an unqualified reference to
|
table. (With the default search path, an unqualified reference to
|
||||||
your table name would then be resolved as the system table instead.)
|
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.
|
or on the <literal>make</literal> command line.
|
||||||
</para>
|
</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>
|
<para>
|
||||||
You can also run <literal>make</literal> in a directory outside the source
|
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.
|
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>
|
<note>
|
||||||
<para>
|
<para>
|
||||||
Prior to <productname>PostgreSQL</productname> 8.0, casting an
|
Casting an integer to <type>bit(n)</> copies the rightmost
|
||||||
integer to <type>bit(n)</> would copy the leftmost <literal>n</>
|
<literal>n</> bits. Casting an integer to a bit string width wider
|
||||||
bits of the integer, whereas now it copies the rightmost <literal>n</>
|
than the integer itself will sign-extend on the left.
|
||||||
bits. Also, casting an integer to a bit string width wider than
|
|
||||||
the integer itself will sign-extend on the left.
|
|
||||||
</para>
|
</para>
|
||||||
</note>
|
</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:
|
If you disagree with this, please write your complaint to:
|
||||||
Pope, Cathedral Saint-Peter of Roma, Vatican.
|
Pope, Cathedral Saint-Peter of Roma, Vatican.
|
||||||
</para>
|
</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>
|
</listitem>
|
||||||
</varlistentry>
|
</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.
|
Years in the 1900s are in the second millennium.
|
||||||
The third millennium started January 1, 2001.
|
The third millennium started January 1, 2001.
|
||||||
</para>
|
</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>
|
</listitem>
|
||||||
</varlistentry>
|
</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
|
next <function>nextval</function> will return exactly the specified
|
||||||
value, and sequence advancement commences with the following
|
value, and sequence advancement commences with the following
|
||||||
<function>nextval</function>. Furthermore, the value reported by
|
<function>nextval</function>. Furthermore, the value reported by
|
||||||
<function>currval</> is not changed in this case (this is a change
|
<function>currval</> is not changed in this case. For example,
|
||||||
from pre-8.3 behavior). For example,
|
|
||||||
|
|
||||||
<screen>
|
<screen>
|
||||||
SELECT setval('foo', 42); <lineannotation>Next <function>nextval</> will return 43</lineannotation>
|
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
|
<literal>PQTRANS_ACTIVE</literal> is reported only when a query
|
||||||
has been sent to the server and not yet completed.
|
has been sent to the server and not yet completed.
|
||||||
</para>
|
</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>
|
</listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
|
|
||||||
|
@ -113,8 +113,7 @@ SELECT * FROM accounts AS a, pgrowlocks('accounts') AS p
|
|||||||
WHERE p.locked_row = a.ctid;
|
WHERE p.locked_row = a.ctid;
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
|
||||||
Be aware however that (as of <productname>PostgreSQL</> 8.3) such a
|
Be aware however that such a query will be very inefficient.
|
||||||
query will be very inefficient.
|
|
||||||
</para>
|
</para>
|
||||||
</sect2>
|
</sect2>
|
||||||
|
|
||||||
|
@ -388,9 +388,8 @@ BEGIN
|
|||||||
END;
|
END;
|
||||||
$$ LANGUAGE plpgsql;
|
$$ LANGUAGE plpgsql;
|
||||||
</programlisting>
|
</programlisting>
|
||||||
The other way, which was the only way available before
|
The other way is to explicitly declare an alias, using the
|
||||||
<productname>PostgreSQL</productname> 8.0, is to explicitly
|
declaration syntax
|
||||||
declare an alias, using the declaration syntax
|
|
||||||
|
|
||||||
<synopsis>
|
<synopsis>
|
||||||
<replaceable>name</replaceable> ALIAS FOR $<replaceable>n</replaceable>;
|
<replaceable>name</replaceable> ALIAS FOR $<replaceable>n</replaceable>;
|
||||||
|
@ -27,12 +27,11 @@
|
|||||||
</tip>
|
</tip>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
As of <productname>PostgreSQL</productname> 7.4, PL/Python is only
|
PL/Python is only available as an <quote>untrusted</> language, meaning
|
||||||
available as an <quote>untrusted</> language, meaning it does not
|
it does not offer any way of restricting what users can do in it and
|
||||||
offer any way of restricting what users can do in it. It has
|
is therefore named <literal>plpythonu</>. A trusted
|
||||||
therefore been renamed to <literal>plpythonu</>. The trusted
|
variant <literal>plpython</> might become available in the future
|
||||||
variant <literal>plpython</> might become available again in future,
|
if a secure execution mechanism is developed in Python. The
|
||||||
if a new secure execution mechanism is developed in Python. The
|
|
||||||
writer of a function in untrusted PL/Python must take care that 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
|
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
|
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.)
|
mostly because of requirements of the SQL standard.)
|
||||||
</para>
|
</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>
|
<para>
|
||||||
While not required, it is recommended that you continue to follow this old
|
While not required, it is recommended that you continue to follow this old
|
||||||
convention of naming cast implementation functions after the target data
|
convention of naming cast implementation functions after the target data
|
||||||
|
@ -236,19 +236,11 @@ CREATE [ [ GLOBAL | LOCAL ] { TEMPORARY | TEMP } | UNLOGGED ] TABLE <replaceable
|
|||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
Prior to <productname>PostgreSQL</productname> 8.0, <command>CREATE
|
The <command>CREATE TABLE AS</command> command allows the user to
|
||||||
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
|
explicitly specify whether OIDs should be included. If the
|
||||||
presence of OIDs is not explicitly specified,
|
presence of OIDs is not explicitly specified,
|
||||||
the <xref linkend="guc-default-with-oids"> configuration variable is
|
the <xref linkend="guc-default-with-oids"> configuration variable is
|
||||||
used. As of <productname>PostgreSQL</productname> 8.1,
|
used.
|
||||||
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>
|
</para>
|
||||||
</refsect1>
|
</refsect1>
|
||||||
|
|
||||||
|
@ -296,15 +296,6 @@
|
|||||||
<refsect1>
|
<refsect1>
|
||||||
<title>Notes</title>
|
<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>
|
<para>
|
||||||
The options <option>--docdir</option>, <option>--pkgincludedir</option>,
|
The options <option>--docdir</option>, <option>--pkgincludedir</option>,
|
||||||
<option>--localedir</option>, <option>--mandir</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>--htmldir</option> was added in <productname>PostgreSQL</> 8.4.
|
||||||
The option <option>--ldflags_ex</option> was added in <productname>PostgreSQL</> 9.0.
|
The option <option>--ldflags_ex</option> was added in <productname>PostgreSQL</> 9.0.
|
||||||
</para>
|
</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>
|
</refsect1>
|
||||||
|
|
||||||
|
|
||||||
|
@ -218,19 +218,6 @@ REINDEX { INDEX | TABLE | DATABASE | SYSTEM } <replaceable class="PARAMETER">nam
|
|||||||
reindex anything.
|
reindex anything.
|
||||||
</para>
|
</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>
|
||||||
|
|
||||||
<refsect1>
|
<refsect1>
|
||||||
|
@ -106,12 +106,9 @@ SELECT [ ALL | DISTINCT [ ON ( <replaceable class="parameter">expression</replac
|
|||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
Prior to <productname>PostgreSQL</> 8.1, the table created by
|
To add OIDs to the table created by <command>SELECT INTO</command>,
|
||||||
<command>SELECT INTO</command> included OIDs by default. In
|
enable the <xref linkend="guc-default-with-oids"> configuration
|
||||||
<productname>PostgreSQL</productname> 8.1, this is not the case
|
variable. Alternatively, <command>CREATE TABLE AS</command> can be
|
||||||
— 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.
|
used with the <literal>WITH OIDS</literal> clause.
|
||||||
</para>
|
</para>
|
||||||
</refsect1>
|
</refsect1>
|
||||||
|
@ -2191,10 +2191,6 @@ CREATE VIEW phone_number WITH (security_barrier) AS
|
|||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</itemizedlist>
|
</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>
|
||||||
|
|
||||||
<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
|
these required items, the cluster configuration files
|
||||||
<filename>postgresql.conf</filename>, <filename>pg_hba.conf</filename>, and
|
<filename>postgresql.conf</filename>, <filename>pg_hba.conf</filename>, and
|
||||||
<filename>pg_ident.conf</filename> are traditionally stored in
|
<filename>pg_ident.conf</filename> are traditionally stored in
|
||||||
<varname>PGDATA</> (although in <productname>PostgreSQL</productname> 8.0 and
|
<varname>PGDATA</>, although it is possible to place them elsewhere.
|
||||||
later, it is possible to place them elsewhere).
|
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<table tocentry="1" id="pgdata-contents-table">
|
<table tocentry="1" id="pgdata-contents-table">
|
||||||
|
@ -1465,11 +1465,9 @@ CREATE FUNCTION test(int, int) RETURNS int
|
|||||||
|
|
||||||
<note>
|
<note>
|
||||||
<para>
|
<para>
|
||||||
Before <productname>PostgreSQL</productname> release 8.0, the requirement
|
<productname>PostgreSQL</productname> requires that <literal>STABLE</>
|
||||||
that <literal>STABLE</> and <literal>IMMUTABLE</> functions cannot modify
|
and <literal>IMMUTABLE</> functions contain no SQL commands other
|
||||||
the database was not enforced by the system. Releases 8.0 and later enforce it
|
than <command>SELECT</> to prevent data modification.
|
||||||
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
|
(This is not a completely bulletproof test, since such functions could
|
||||||
still call <literal>VOLATILE</> functions that modify the database.
|
still call <literal>VOLATILE</> functions that modify the database.
|
||||||
If you do that, you will find that the <literal>STABLE</> or
|
If you do that, you will find that the <literal>STABLE</> or
|
||||||
|
Loading…
x
Reference in New Issue
Block a user