Skip to content

P
Postgres FD Implementation
Commit efe3de07 authored by Bruce Momjian's avatar Bruce Momjian
Browse files
Options

Removes or minimizes some documentation mentions of backward 

compatibility for release 7.2 and earlier.  I have not altered any
mentions of release 7.3 or later.  The release notes were not modified,
so the changes are still documented, just not in the main docs.
parent 4799cd7f
Hide whitespace changes
Inline Side-by-side
Showing with 75 additions and 204 deletions
doc/src/sgml/array.sgml
View file @ efe3de07
<!-- $PostgreSQL: pgsql/doc/src/sgml/array.sgml,v 1.48 2005/11/19 01:50:08 tgl Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/array.sgml,v 1.49 2006/04/23 03:39:47 momjian Exp $ -->
<sect1 id="arrays">
<title>Arrays</title>
......@@ -559,8 +559,7 @@ SELECT * FROM sal_emp WHERE 10000 = ALL (pay_by_quarter);
embedded in element values will be backslash-escaped. For numeric
data types it is safe to assume that double quotes will never appear, but
for textual data types one should be prepared to cope with either presence
or absence of quotes. (This is a change in behavior from pre-7.2
<productname>PostgreSQL</productname> releases.)
or absence of quotes.
</para>
<para>
......
doc/src/sgml/backup.sgml
View file @ efe3de07
<!-- $PostgreSQL: pgsql/doc/src/sgml/backup.sgml,v 2.79 2006/03/10 19:10:46 momjian Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/backup.sgml,v 2.80 2006/04/23 03:39:48 momjian Exp $ -->
<chapter id="backup">
<title>Backup and Restore</title>
......@@ -1211,8 +1211,8 @@ restore_command = 'copy /mnt/server/archivedir/%f "%p"' # Windows
the number after the first dot changes). This does not apply to
different minor releases under the same major release (where the
number after the second dot changes); these always have compatible
storage formats. For example, releases 7.0.1, 7.1.2, and 7.2 are
not compatible, whereas 7.1.1 and 7.1.2 are. When you update
storage formats. For example, releases 7.2.1, 7.3.2, and 7.4 are
not compatible, whereas 7.2.1 and 7.2.2 are. When you update
between compatible versions, you can simply replace the executables
and reuse the data directory on disk. Otherwise you need to back
up your data and restore it on the new server. This has to be done
......
doc/src/sgml/config.sgml
View file @ efe3de07
<!-- $PostgreSQL: pgsql/doc/src/sgml/config.sgml,v 1.54 2006/04/18 12:41:15 momjian Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/config.sgml,v 1.55 2006/04/23 03:39:48 momjian Exp $ -->
<chapter Id="runtime-config">
<title>Server Configuration</title>
......@@ -3789,14 +3789,11 @@ dynamic_library_path = 'C:\tools\postgresql;H:\my_project\lib;$libdir'
<indexterm><primary>inheritance</></>
<listitem>
<para>
This controls the inheritance semantics, in particular whether
subtables are included by various commands by default. They were
not included in versions prior to 7.1. If you need the old
behavior you can set this variable to <literal>off</>, but in
the long run you are encouraged to change your applications to
use the <literal>ONLY</literal> key word to exclude subtables.
See <xref linkend="ddl-inherit"> for more information about
inheritance.
This controls the inheritance semantics. If turned <literal>off</>,
subtables are not included by various commands by default; basically
an implied <literal>ONLY</literal> key word. This was added for
compatibility with releases prior to 7.1. See
<xref linkend="ddl-inherit"> for more information.
</para>
</listitem>
</varlistentry>
......
doc/src/sgml/datatype.sgml
View file @ efe3de07
<!-- $PostgreSQL: pgsql/doc/src/sgml/datatype.sgml,v 1.166 2006/03/10 19:10:47 momjian Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/datatype.sgml,v 1.167 2006/04/23 03:39:49 momjian Exp $ -->
<chapter id="datatype">
<title id="datatype-title">Data Types</title>
......@@ -894,22 +894,14 @@ CREATE TABLE <replaceable class="parameter">tablename</replaceable> (
string.
</para>
<para>
If one explicitly casts a value to <type>character
varying(<replaceable>n</>)</type> or
<type>character(<replaceable>n</>)</type>, then an over-length
value will be truncated to <replaceable>n</> characters without
raising an error. (This too is required by the
<acronym>SQL</acronym> standard.)
</para>
<note>
<para>
Prior to <productname>PostgreSQL</> 7.2, strings that were too long were
always truncated without raising an error, in either explicit or
implicit casting contexts.
</para>
</note>
<para>
If one explicitly casts a value to <type>character
varying(<replaceable>n</>)</type> or
<type>character(<replaceable>n</>)</type>, then an over-length
value will be truncated to <replaceable>n</> characters without
raising an error. (This too is required by the
<acronym>SQL</acronym> standard.)
</para>
<para>
The notations <type>varchar(<replaceable>n</>)</type> and
......@@ -2899,15 +2891,6 @@ SELECT * FROM test1 WHERE a;
</para>
</note>
<note>
<para>
Prior to <productname>PostgreSQL</> 7.2, <type>bit</type> data
was always silently truncated or zero-padded on the right, with
or without an explicit cast. This was changed to comply with the
<acronym>SQL</acronym> standard.
</para>
</note>
<para>
Refer to <xref
linkend="sql-syntax-bit-strings"> for information about the syntax
......
doc/src/sgml/datetime.sgml
View file @ efe3de07
<!-- $PostgreSQL: pgsql/doc/src/sgml/datetime.sgml,v 2.48 2006/03/10 19:10:47 momjian Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/datetime.sgml,v 2.49 2006/04/23 03:39:50 momjian Exp $ -->
<appendix id="datetime-appendix">
<title>Date/Time Support</title>
......@@ -171,10 +171,7 @@
<tip>
<para>
Gregorian years AD 1-99 may be entered by using 4 digits with leading
zeros (e.g., <literal>0099</> is AD 99). Previous versions of
<productname>PostgreSQL</productname> accepted years with three
digits and with single digits, but as of version 7.0 the rules have
been tightened up to reduce the possibility of ambiguity.
zeros (e.g., <literal>0099</> is AD 99).
</para>
</tip>
</para>
......
doc/src/sgml/ddl.sgml
View file @ efe3de07
<!-- $PostgreSQL: pgsql/doc/src/sgml/ddl.sgml,v 1.55 2006/02/18 23:14:45 neilc Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/ddl.sgml,v 1.56 2006/04/23 03:39:50 momjian Exp $ -->
<chapter id="ddl">
<title>Data Definition</title>
......@@ -2145,21 +2145,11 @@ VALUES ('New York', NULL, NULL, 'NY');
<note>
<title>Deprecated</title>
<para>
In previous versions of <productname>PostgreSQL</productname>, the
In releases of <productname>PostgreSQL</productname> prior to 7.1, the
default behavior was not to include child tables in queries. This was
found to be error prone and is also in violation of the SQL
standard. Under the old syntax, to include the child tables you append
<literal>*</literal> to the table name. For example:
<programlisting>
SELECT * from cities*;
</programlisting>
You can still explicitly specify scanning child tables by
appending <literal>*</literal>, as well as explicitly specify not
scanning child tables by writing <literal>ONLY</literal>. But
beginning in version 7.1, the default behavior for an undecorated
table name is to scan its child tables too, whereas before the
default was not to do so. To get the old default behavior,
disable the <xref linkend="guc-sql-inheritance"> configuration
found to be error prone and also in violation of the SQL
standard. You can get the pre-7.1 behavior by turning off the
<xref linkend="guc-sql-inheritance"> configuration
option.
</para>
</note>
......
doc/src/sgml/func.sgml
View file @ efe3de07
<!-- $PostgreSQL: pgsql/doc/src/sgml/func.sgml,v 1.313 2006/03/10 20:15:25 neilc Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/func.sgml,v 1.314 2006/04/23 03:39:50 momjian Exp $ -->
<chapter id="functions">
<title>Functions and Operators</title>
......@@ -6118,14 +6118,6 @@ LOCALTIMESTAMP (<replaceable>precision</replaceable>)
the result is given to the full available precision.
</para>
<note>
<para>
Prior to <productname>PostgreSQL</productname> 7.2, the precision
parameters were unimplemented, and the result was always given
in integer seconds.
</para>
</note>
<para>
Some examples:
<screen>
......
doc/src/sgml/libpq.sgml
View file @ efe3de07
<!-- $PostgreSQL: pgsql/doc/src/sgml/libpq.sgml,v 1.206 2006/03/10 19:10:48 momjian Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/libpq.sgml,v 1.207 2006/04/23 03:39:51 momjian Exp $ -->
<chapter id="libpq">
<title><application>libpq</application> - C Library</title>
......@@ -686,14 +686,10 @@ PostgresPollingStatusType PQresetPoll(PGconn *conn);
<indexterm><primary>libpq-int.h</></>
<application>libpq</application> application programmers should be careful to
maintain the <structname>PGconn</structname> abstraction. Use the accessor
functions described below to get
at the contents of <structname>PGconn</structname>. Avoid directly referencing the fields of the
<structname>PGconn</> structure because they are subject to change in the future.
(Beginning in <productname>PostgreSQL</productname> release 6.4, the
definition of the <type>struct</type> behind <structname>PGconn</> is not even provided in <filename>libpq-fe.h</filename>.
If you have old code that accesses <structname>PGconn</structname> fields directly, you can keep using it
by including <filename>libpq-int.h</filename> too, but you are encouraged to fix the code
soon.)
functions described below to get at the contents of <structname>PGconn</structname>.
Reference to internal <structname>PGconn</structname> fields using
<filename>libpq-int.h</> is not recommended because they are subject to change
in the future.
</para>
</tip>
......@@ -2972,7 +2968,7 @@ PGnotify *PQnotifies(PGconn *conn);
typedef struct pgNotify {
char *relname; /* notification condition name */
int be_pid; /* process ID of server process */
int be_pid; /* process ID of notifying server process */
char *extra; /* notification parameter */
} PGnotify;
</synopsis>
......@@ -2986,14 +2982,6 @@ do not represent separate allocations.
always point to an empty string.)
</para>
<note>
<para>
In <productname>PostgreSQL</productname> 6.4 and later,
the <structfield>be_pid</structfield> is that of the notifying server process,
whereas in earlier versions it was always the <acronym>PID</acronym> of your own server process.
</para>
</note>
<para>
<xref linkend="libpq-example-2"> gives a sample program that illustrates the use
of asynchronous notification.
......@@ -4288,16 +4276,6 @@ testlibpq.o(.text+0xa4): undefined reference to `PQerrorMessage'
</itemizedlist>
</para>
<para>
<indexterm><primary>libpq-int.h</></>
If your codes references the header file
<filename>libpq-int.h</filename> and you refuse to fix your code to
not use it, starting in <productname>PostgreSQL</> 7.2, this file will be found in
<filename><replaceable>includedir</replaceable>/postgresql/internal/libpq-int.h</filename>,
so you need to add the appropriate <option>-I</option> option to
your compiler command line.
</para>
</sect1>
......
doc/src/sgml/lobj.sgml
View file @ efe3de07
<!-- $PostgreSQL: pgsql/doc/src/sgml/lobj.sgml,v 1.39 2006/03/10 19:10:48 momjian Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/lobj.sgml,v 1.40 2006/04/23 03:39:52 momjian Exp $ -->
<chapter id="largeObjects">
<title id="largeObjects-title">Large Objects</title>
......@@ -25,43 +25,26 @@
values. This is not described here.
</para>
<sect1 id="lo-history">
<title>History</title>
<sect1 id="lo-intro">
<title>Introduction</title>
<para>
<productname>POSTGRES 4.2</productname>, the indirect predecessor
of <productname>PostgreSQL</productname>, supported three standard
implementations of large objects: as files external to the
<productname>POSTGRES</productname> server, as external files
managed by the <productname>POSTGRES</productname> server, and as
data stored within the <productname>POSTGRES</productname>
database. This caused considerable confusion among users. As a
result, only support for large objects as data stored within the
database is retained in <productname>PostgreSQL</productname>.
Even though this is slower to access, it provides stricter data
integrity. For historical reasons, this storage scheme is
referred to as <firstterm>Inversion large
objects</firstterm>. (You will see the term Inversion used
occasionally to mean the same thing as large object.) Since
<productname>PostgreSQL 7.1</productname>, all large objects are
placed in one system table called
<classname>pg_largeobject</classname>.
</para>
<indexterm>
<primary>TOAST</primary>
<secondary>versus large objects</secondary>
</indexterm>
<para>
<indexterm>
<primary>TOAST</primary>
<secondary>versus large objects</secondary>
</indexterm>
<productname>PostgreSQL</productname> 7.1 introduced a mechanism
(nicknamed <quote><acronym>TOAST</acronym></quote>) that allows
data values to be much larger than single pages. This
makes the large object facility partially obsolete. One
All large objects are placed in a single system table called
<classname>pg_largeobject</classname>.
<productname>PostgreSQL</productname> also supports a storage system called
<quote><acronym>TOAST</acronym></quote> that automatically stores values
larger than a single database page into a secondary storage area per table.
This makes the large object facility partially obsolete. One
remaining advantage of the large object facility is that it allows values
up to 2 GB in size, whereas <acronym>TOAST</acronym>ed fields can be at
most 1 GB. Also, large objects can be manipulated piece-by-piece much more
easily than ordinary data fields, so the practical limits are considerably
different.
most 1 GB. Also, large objects can be randomly modified using a read/write
API that is more efficient than performing such operations using
<acronym>TOAST</acronym>.
</para>
</sect1>
......@@ -70,8 +53,8 @@
<title>Implementation Features</title>
<para>
The large object implementation breaks large
objects up into <quote>chunks</quote> and stores the chunks in
The large object implementation breaks large
objects up into <quote>chunks</quote> and stores the chunks in
rows in the database. A B-tree index guarantees fast
searches for the correct chunk number when doing random
access reads and writes.
......@@ -86,10 +69,7 @@
<productname>PostgreSQL</productname> client interface libraries
provide for accessing large objects. All large object
manipulation using these functions <emphasis>must</emphasis> take
place within an SQL transaction block. (This requirement is
strictly enforced as of <productname>PostgreSQL 6.5</>, though it
has been an implicit requirement in previous versions, resulting
in misbehavior if ignored.)
place within an SQL transaction block.
The <productname>PostgreSQL</productname> large object interface is modeled after
the <acronym>Unix</acronym> file-system interface, with analogues of
<function>open</function>, <function>read</function>,
......
doc/src/sgml/maintenance.sgml
View file @ efe3de07
<!-- $PostgreSQL: pgsql/doc/src/sgml/maintenance.sgml,v 1.54 2006/03/10 19:10:48 momjian Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/maintenance.sgml,v 1.55 2006/04/23 03:39:52 momjian Exp $ -->
<chapter id="maintenance">
<title>Routine Database Maintenance Tasks</title>
......@@ -82,15 +82,9 @@
</para>
<para>
Beginning in <productname>PostgreSQL</productname> 7.2, the standard form
of <command>VACUUM</> can run in parallel with normal database operations
(selects, inserts, updates, deletes, but not changes to table definitions).
Routine vacuuming is therefore not nearly as intrusive as it was in prior
releases, and it is not as critical to try to schedule it at low-usage
times of day.
</para>
<para>
The standard form of <command>VACUUM</> can run in parallel with
normal database operations (SELECTs, INSERTs, UPDATEs, DELETEs, but not
changes to table definitions).
Beginning in <productname>PostgreSQL</productname> 8.0, there are
configuration parameters that can be adjusted to further reduce the
performance impact of background vacuuming. See
......@@ -245,12 +239,9 @@
It is possible to run <command>ANALYZE</> on specific tables and even
just specific columns of a table, so the flexibility exists to update some
statistics more frequently than others if your application requires it.
In practice, however, the usefulness of this feature is doubtful.
Beginning in <productname>PostgreSQL</productname> 7.2,
<command>ANALYZE</> is a fairly fast operation even on large tables,
because it uses a statistical random sampling of the rows of a table
rather than reading every single row. So it's probably much simpler
to just run it over the whole database every so often.
In practice, however, it is usually best to just analyze the entire database
because it is a fast operation. It uses a statistical random sampling of
the rows of a table rather than reading every single row.
</para>
<tip>
......@@ -295,18 +286,8 @@
transactions that were in the past appear to be in the future &mdash; which
means their outputs become invisible. In short, catastrophic data loss.
(Actually the data is still there, but that's cold comfort if you can't
get at it.)
</para>
<para>
Prior to <productname>PostgreSQL</productname> 7.2, the only defense
against XID wraparound was to re-<command>initdb</> at least every 4
billion transactions. This of course was not very satisfactory for
high-traffic sites, so a better solution has been devised. The new
approach allows a server to remain up indefinitely, without
<command>initdb</> or any sort of restart. The price is this
maintenance requirement: <emphasis>every table in the database must
be vacuumed at least once every billion transactions</emphasis>.
get at it.) To avoid this, it is <emphasis>necessary to vacuum every table
in every database at least once every billion transactions</emphasis>.
</para>
<para>
......
doc/src/sgml/mvcc.sgml
View file @ efe3de07
<!-- $PostgreSQL: pgsql/doc/src/sgml/mvcc.sgml,v 2.55 2006/03/10 19:10:48 momjian Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/mvcc.sgml,v 2.56 2006/04/23 03:39:52 momjian Exp $ -->
<chapter id="mvcc">
<title>Concurrency Control</title>
......@@ -899,10 +899,6 @@ UPDATE accounts SET balance = balance - 100.00 WHERE acctnum = 22222;
TABLE</command> locks the whole table.) This should be taken into
account when porting applications to
<productname>PostgreSQL</productname> from other environments.
(Before version 6.5 <productname>PostgreSQL</productname> used
read locks, and so this above consideration is also relevant when
upgrading from <productname>PostgreSQL</productname> versions
prior to 6.5.)
</para>
<para>
......
doc/src/sgml/rules.sgml
View file @ efe3de07
<!-- $PostgreSQL: pgsql/doc/src/sgml/rules.sgml,v 1.44 2005/10/22 14:44:35 alvherre Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/rules.sgml,v 1.45 2006/04/23 03:39:52 momjian Exp $ -->
<chapter id="rules">
<title>The Rule System</title>
......@@ -2043,10 +2043,7 @@ Nestloop
<para>
Another situation is cases on <command>UPDATE</command> where it depends on the
change of an attribute if an action should be performed or
not. In <productname>PostgreSQL</productname> version 6.4, the
attribute specification for rule events is disabled (it will have
its comeback latest in 6.5, maybe earlier
- stay tuned). So for now the only way to
not. The only way to
create a rule as in the shoelace_log example is to do it with
a rule qualification. That results in an extra query that is
performed always, even if the attribute of interest cannot
......
doc/src/sgml/storage.sgml
View file @ efe3de07
<!-- $PostgreSQL: pgsql/doc/src/sgml/storage.sgml,v 1.9 2006/03/10 19:10:49 momjian Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/storage.sgml,v 1.10 2006/04/23 03:39:52 momjian Exp $ -->
<chapter id="storage">
......@@ -187,15 +187,13 @@ Oversized-Attribute Storage Technique).
</para>
<para>
Since <productname>PostgreSQL</productname> uses a fixed page size (commonly
8Kb), and does not allow tuples to span multiple pages, it's not possible to
store very large field values directly. Before <productname>PostgreSQL</> 7.1
there was a hard limit of just under one page on the total amount of data that
could be put into a table row. In release 7.1 and later, this limit is
overcome by allowing large field values to be compressed and/or broken up into
multiple physical rows. This happens transparently to the user, with only
small impact on most of the backend code. The technique is affectionately
known as <acronym>TOAST</> (or <quote>the best thing since sliced bread</>).
<productname>PostgreSQL</productname> uses a fixed page size (commonly
8Kb), and does not allow tuples to span multiple pages. Therefore, it is
not possible to store very large field values directly. To overcome
this limitation, large field values are compressed and/or broken up into
multiple physical rows. This happens transparently to the user, with only
small impact on most of the backend code. The technique is affectionately
known as <acronym>TOAST</> (or <quote>the best thing since sliced bread</>).
</para>
<para>
......
doc/src/sgml/xfunc.sgml
View file @ efe3de07
<!-- $PostgreSQL: pgsql/doc/src/sgml/xfunc.sgml,v 1.111 2006/03/10 19:10:49 momjian Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/xfunc.sgml,v 1.112 2006/04/23 03:39:52 momjian Exp $ -->
<sect1 id="xfunc">
<title>User-Defined Functions</title>
......@@ -1192,15 +1192,6 @@ CREATE FUNCTION square_root(double precision) RETURNS double precision
command <literal>pg_config --pkglibdir</literal>.
</para>
<para>
Before <productname>PostgreSQL</productname> release 7.2, only
exact absolute paths to object files could be specified in
<command>CREATE FUNCTION</>. This approach is now deprecated
since it makes the function definition unnecessarily unportable.
It's best to specify just the shared library name with no path nor
extension, and let the search mechanism provide that information
instead.
</para>
</sect2>
<sect2 id="xfunc-c-basetype">
......@@ -1915,15 +1906,7 @@ concat_text(PG_FUNCTION_ARGS)
--includedir-server</literal><indexterm><primary>pg_config</><secondary>with user-defined C functions</></>
to find out where the <productname>PostgreSQL</> server header
files are installed on your system (or the system that your
users will be running on). This option is new with
<productname>PostgreSQL</> 7.2. For
<productname>PostgreSQL</> 7.1 you should use the option
<option>--includedir</option>. (<command>pg_config</command>
will exit with a non-zero status if it encounters an unknown
option.) For releases prior to 7.1 you will have to guess,
but since that was before the current calling conventions were
introduced, it is unlikely that you want to support those
releases.
users will be running on).
</para>
</listitem>
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment