diff --git a/doc/src/sgml/array.sgml b/doc/src/sgml/array.sgml
index 9255144999..81df5e4de9 100644
--- a/doc/src/sgml/array.sgml
+++ b/doc/src/sgml/array.sgml
@@ -1,4 +1,4 @@
-
+
Arrays
@@ -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
- PostgreSQL releases.)
+ or absence of quotes.
diff --git a/doc/src/sgml/backup.sgml b/doc/src/sgml/backup.sgml
index 7ba5b52295..199044a3ef 100644
--- a/doc/src/sgml/backup.sgml
+++ b/doc/src/sgml/backup.sgml
@@ -1,4 +1,4 @@
-
+
Backup and Restore
@@ -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
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index d746fccfdf..2ec9c3026c 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -1,4 +1,4 @@
-
+
Server Configuration
@@ -3789,14 +3789,11 @@ dynamic_library_path = 'C:\tools\postgresql;H:\my_project\lib;$libdir'
inheritance
- 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 off, but in
- the long run you are encouraged to change your applications to
- use the ONLY key word to exclude subtables.
- See for more information about
- inheritance.
+ This controls the inheritance semantics. If turned off,
+ subtables are not included by various commands by default; basically
+ an implied ONLY key word. This was added for
+ compatibility with releases prior to 7.1. See
+ for more information.
diff --git a/doc/src/sgml/datatype.sgml b/doc/src/sgml/datatype.sgml
index 2e3dc7a434..cdb55a2b52 100644
--- a/doc/src/sgml/datatype.sgml
+++ b/doc/src/sgml/datatype.sgml
@@ -1,4 +1,4 @@
-
+
Data Types
@@ -894,22 +894,14 @@ CREATE TABLE tablename (
string.
-
- If one explicitly casts a value to character
- varying(n) or
- character(n), then an over-length
- value will be truncated to n characters without
- raising an error. (This too is required by the
- SQL standard.)
-
-
-
-
- Prior to PostgreSQL 7.2, strings that were too long were
- always truncated without raising an error, in either explicit or
- implicit casting contexts.
-
-
+
+ If one explicitly casts a value to character
+ varying(n) or
+ character(n), then an over-length
+ value will be truncated to n characters without
+ raising an error. (This too is required by the
+ SQL standard.)
+
The notations varchar(n) and
@@ -2899,15 +2891,6 @@ SELECT * FROM test1 WHERE a;
-
-
- Prior to PostgreSQL 7.2, bit data
- was always silently truncated or zero-padded on the right, with
- or without an explicit cast. This was changed to comply with the
- SQL standard.
-
-
-
Refer to for information about the syntax
diff --git a/doc/src/sgml/datetime.sgml b/doc/src/sgml/datetime.sgml
index 5d6789e253..3603a6156e 100644
--- a/doc/src/sgml/datetime.sgml
+++ b/doc/src/sgml/datetime.sgml
@@ -1,4 +1,4 @@
-
+
Date/Time Support
@@ -171,10 +171,7 @@
Gregorian years AD 1-99 may be entered by using 4 digits with leading
- zeros (e.g., 0099 is AD 99). Previous versions of
- PostgreSQL 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., 0099 is AD 99).
diff --git a/doc/src/sgml/ddl.sgml b/doc/src/sgml/ddl.sgml
index e7d590dfac..77bc1dd497 100644
--- a/doc/src/sgml/ddl.sgml
+++ b/doc/src/sgml/ddl.sgml
@@ -1,4 +1,4 @@
-
+
Data Definition
@@ -2145,21 +2145,11 @@ VALUES ('New York', NULL, NULL, 'NY');
Deprecated
- In previous versions of PostgreSQL, the
+ In releases of PostgreSQL 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
- * to the table name. For example:
-
-SELECT * from cities*;
-
- You can still explicitly specify scanning child tables by
- appending *, as well as explicitly specify not
- scanning child tables by writing ONLY. 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 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
+ configuration
option.
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index f7adaab009..0b5fb01e4d 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -1,4 +1,4 @@
-
+
Functions and Operators
@@ -6118,14 +6118,6 @@ LOCALTIMESTAMP (precision)
the result is given to the full available precision.
-
-
- Prior to PostgreSQL 7.2, the precision
- parameters were unimplemented, and the result was always given
- in integer seconds.
-
-
-
Some examples:
diff --git a/doc/src/sgml/libpq.sgml b/doc/src/sgml/libpq.sgml
index 7308ecc9cb..fdcd4eb9c1 100644
--- a/doc/src/sgml/libpq.sgml
+++ b/doc/src/sgml/libpq.sgml
@@ -1,4 +1,4 @@
-
+
<application>libpq</application> - C Library
@@ -686,14 +686,10 @@ PostgresPollingStatusType PQresetPoll(PGconn *conn);
libpq-int.h
libpq application programmers should be careful to
maintain the PGconn abstraction. Use the accessor
-functions described below to get
-at the contents of PGconn. Avoid directly referencing the fields of the
-PGconn structure because they are subject to change in the future.
-(Beginning in PostgreSQL release 6.4, the
-definition of the struct behind PGconn is not even provided in libpq-fe.h.
-If you have old code that accesses PGconn fields directly, you can keep using it
-by including libpq-int.h too, but you are encouraged to fix the code
-soon.)
+functions described below to get at the contents of PGconn.
+Reference to internal PGconn fields using
+libpq-int.h is not recommended because they are subject to change
+in the future.
@@ -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;
@@ -2986,14 +2982,6 @@ do not represent separate allocations.
always point to an empty string.)
-
-
- In PostgreSQL 6.4 and later,
- the be_pid is that of the notifying server process,
- whereas in earlier versions it was always the PID of your own server process.
-
-
-
gives a sample program that illustrates the use
of asynchronous notification.
@@ -4288,16 +4276,6 @@ testlibpq.o(.text+0xa4): undefined reference to `PQerrorMessage'
-
- libpq-int.h
- If your codes references the header file
- libpq-int.h and you refuse to fix your code to
- not use it, starting in PostgreSQL 7.2, this file will be found in
- includedir/postgresql/internal/libpq-int.h,
- so you need to add the appropriate option to
- your compiler command line.
-
-
diff --git a/doc/src/sgml/lobj.sgml b/doc/src/sgml/lobj.sgml
index 86d60a3932..4572cfa776 100644
--- a/doc/src/sgml/lobj.sgml
+++ b/doc/src/sgml/lobj.sgml
@@ -1,4 +1,4 @@
-
+
Large Objects
@@ -25,43 +25,26 @@
values. This is not described here.
-
- History
+
+ Introduction
+
+
+ TOAST
+ versus large objects
+
- POSTGRES 4.2, the indirect predecessor
- of PostgreSQL, supported three standard
- implementations of large objects: as files external to the
- POSTGRES server, as external files
- managed by the POSTGRES server, and as
- data stored within the POSTGRES
- database. This caused considerable confusion among users. As a
- result, only support for large objects as data stored within the
- database is retained in PostgreSQL.
- Even though this is slower to access, it provides stricter data
- integrity. For historical reasons, this storage scheme is
- referred to as Inversion large
- objects. (You will see the term Inversion used
- occasionally to mean the same thing as large object.) Since
- PostgreSQL 7.1, all large objects are
- placed in one system table called
+ All large objects are placed in a single system table called
pg_largeobject.
-
-
-
-
- TOAST
- versus large objects
-
- PostgreSQL 7.1 introduced a mechanism
- (nicknamed TOAST) that allows
- data values to be much larger than single pages. This
- makes the large object facility partially obsolete. One
+ PostgreSQL also supports a storage system called
+ TOAST 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 TOASTed 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
+ TOAST.
@@ -70,8 +53,8 @@
Implementation Features
- The large object implementation breaks large
- objects up into chunks and stores the chunks in
+ The large object implementation breaks large
+ objects up into chunks 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 @@
PostgreSQL client interface libraries
provide for accessing large objects. All large object
manipulation using these functions must take
- place within an SQL transaction block. (This requirement is
- strictly enforced as of 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 PostgreSQL large object interface is modeled after
the Unix file-system interface, with analogues of
open, read,
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b2355cfa02..fa7423d5c3 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -1,4 +1,4 @@
-
+
Routine Database Maintenance Tasks
@@ -82,15 +82,9 @@
- Beginning in PostgreSQL 7.2, the standard form
- of 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.
-
-
-
+ The standard form of VACUUM can run in parallel with
+ normal database operations (SELECTs, INSERTs, UPDATEs, DELETEs, but not
+ changes to table definitions).
Beginning in PostgreSQL 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 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 PostgreSQL 7.2,
- 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.
@@ -295,18 +286,8 @@
transactions that were in the past appear to be in the future — 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.)
-
-
-
- Prior to PostgreSQL 7.2, the only defense
- against XID wraparound was to re-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
- initdb or any sort of restart. The price is this
- maintenance requirement: every table in the database must
- be vacuumed at least once every billion transactions.
+ get at it.) To avoid this, it is necessary to vacuum every table
+ in every database at least once every billion transactions.
diff --git a/doc/src/sgml/mvcc.sgml b/doc/src/sgml/mvcc.sgml
index 5cd9c995fe..8ebb820519 100644
--- a/doc/src/sgml/mvcc.sgml
+++ b/doc/src/sgml/mvcc.sgml
@@ -1,4 +1,4 @@
-
+
Concurrency Control
@@ -899,10 +899,6 @@ UPDATE accounts SET balance = balance - 100.00 WHERE acctnum = 22222;
TABLE locks the whole table.) This should be taken into
account when porting applications to
PostgreSQL from other environments.
- (Before version 6.5 PostgreSQL used
- read locks, and so this above consideration is also relevant when
- upgrading from PostgreSQL versions
- prior to 6.5.)
diff --git a/doc/src/sgml/rules.sgml b/doc/src/sgml/rules.sgml
index 45a1b14582..ad5a2d4bfe 100644
--- a/doc/src/sgml/rules.sgml
+++ b/doc/src/sgml/rules.sgml
@@ -1,4 +1,4 @@
-
+
The Rule System
@@ -2043,10 +2043,7 @@ Nestloop
Another situation is cases on UPDATE where it depends on the
change of an attribute if an action should be performed or
- not. In PostgreSQL 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
diff --git a/doc/src/sgml/storage.sgml b/doc/src/sgml/storage.sgml
index c48ce73de4..5430be9ad2 100644
--- a/doc/src/sgml/storage.sgml
+++ b/doc/src/sgml/storage.sgml
@@ -1,4 +1,4 @@
-
+
@@ -187,15 +187,13 @@ Oversized-Attribute Storage Technique).
-Since PostgreSQL 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 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 TOAST (or the best thing since sliced bread).
+PostgreSQL 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 TOAST (or the best thing since sliced bread).
diff --git a/doc/src/sgml/xfunc.sgml b/doc/src/sgml/xfunc.sgml
index 320288e0a4..27cb8c90ca 100644
--- a/doc/src/sgml/xfunc.sgml
+++ b/doc/src/sgml/xfunc.sgml
@@ -1,4 +1,4 @@
-
+
User-Defined Functions
@@ -1192,15 +1192,6 @@ CREATE FUNCTION square_root(double precision) RETURNS double precision
command pg_config --pkglibdir.
-
- Before PostgreSQL release 7.2, only
- exact absolute paths to object files could be specified in
- 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.
-
@@ -1915,15 +1906,7 @@ concat_text(PG_FUNCTION_ARGS)
--includedir-serverpg_configwith user-defined C functions
to find out where the PostgreSQL server header
files are installed on your system (or the system that your
- users will be running on). This option is new with
- PostgreSQL 7.2. For
- PostgreSQL 7.1 you should use the option
- . (pg_config
- 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).