Update release notes in "major" and "migration" sections. Still have

remainder of release notes to review.

doc/src/sgml/release.sgml

-<!-- $PostgreSQL: pgsql/doc/src/sgml/release.sgml,v 1.517 2007/10/10 14:09:49 momjian Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/release.sgml,v 1.518 2007/10/11 19:46:21 momjian Exp $ -->
 <!--
 
 Typical markup:
@@ -40,7 +40,7 @@ do it for earlier branch release files.
 
    <note>
     <title>Release date</title>
-    <simpara>2007-??-??</simpara>
+    <simpara>2007-12-??</simpara>
     <para>CURRENT AS OF 2007-10-03</>
    </note>
 
@@ -48,33 +48,48 @@ do it for earlier branch release files.
     <title>Overview</title>
 
     <para>
-     This release adds many improvements that were requested by users,
-     including:
+     This release represents a major leap forward by adding significant
+     new functionality and performance enhancements to
+     <productname>PostgreSQL</>. Many complex ideas that normally take
+     years to implement were added rapidly to this release by our
+     development team. This release starts <productname>PostgreSQL</> on
+     a trajectory moving beyond feature-parity with other database
+     systems to a time when <productname>PostgreSQL</> will be a
+     technology leader in the database field. Major new capabilities
+     this release include:
 
     <itemizedlist>
 
       <listitem>
        <para>
-        Full text search is now a built-in feature
+        Full text search now fully integrated into the core database
+        system
        </para>
       </listitem>
 
       <listitem>
        <para>
-        Support for the SQL/XML standard, including a new <type>xml</type> builtin
+        Support for the SQL/XML standard, including a new <type>XML</type> builtin
         data type
        </para>
       </listitem>
 
       <listitem>
        <para>
-        enum data types
+        Enumerated (<type>ENUM</>) data type support
+       </para>
+
+       <para>
+        This is accomplished by creating a new data type with an
+        <literal>ENUM</> clause, e.g.
+        <literal>CREATE TYPE mood AS ENUM ('sad', 'ok', 'happy')</>.
        </para>
       </listitem>
 
       <listitem>
        <para>
-        UUID data type, similar to that defined by RFC 4122
+        Universally Unique Identifier (UUID) data type, similar to that
+        defined by RFC 4122
        </para>
       </listitem>
 
@@ -86,52 +101,68 @@ do it for earlier branch release files.
 
       <listitem>
        <para>
+        Control of whether <literal>NULL</>s sort first or last, using
         <literal>ORDER BY ... NULLS FIRST/LAST</>
        </para>
       </listitem>
 
       <listitem>
        <para>
-        Updatable cursors
-        (<literal>UPDATE/DELETE WHERE CURRENT OF</>
-        <replaceable>cursor_name</>)
+        Updatable cursors using <literal>UPDATE/DELETE WHERE CURRENT OF</>
+       </para>
+
+       <para>
+        This eliminates the need to reference a primary key to update or
+        delete rows returned by a cursor.
        </para>
       </listitem>
 
       <listitem>
        <para>
-        Per-function parameter settings
+        Server configuration parameters can now be set on a per-function
+        basis
+       </para>
+
+       <para>
+        For example, functions can now set their own
+        <varname>search_path</> to prevent unexpected behavior if a
+        different <varname>search_path</> exists at run-time.
        </para>
       </listitem>
 
       <listitem>
        <para>
-        User-defined types can now have type modifiers (parameters)
+        User-defined types can now have type modifiers
        </para>
 
        <para>
-        Declarations such as <type>varchar(42)</type> are no longer
-        restricted to use by built-in data types.
+        This allows a user type to take a modifier when
+        being referenced, e.g. <type>SSNUM(7)</>.  Previously only
+        predefined system data types would allow this, e.g.
+        <type>CHAR(4)</>.
        </para>
       </listitem>
 
       <listitem>
        <para>
-        Automatic plan invalidation when table definitions change
+        Automatically invalidate cached function code when table
+        definitions change
        </para>
 
        <para>
-        This will particularly ease usage of temporary tables in
-        PL/PgSQL functions.
+        Previously PL/pgSQL functions that referenced temporary tables
+        would fail if the temporary table was dropped and recreated
+        between function invocations, unless <literal>EXECUTE</> was
+        used.
        </para>
       </listitem>
 
       <listitem>
        <para>
-        Numerous improvements in logging and statistics collection
-        capabilities, including the ability to emit postmaster log messages
-        in CSV format that can be directly loaded into a database table
-        for analysis
+        Numerous improvements in logging and statistics collection,
+        including the ability to emit postmaster log messages in
+        <acronym>CSV</> format, which can be loaded into a database
+        table for analysis
        </para>
       </listitem>
 
@@ -139,6 +170,11 @@ do it for earlier branch release files.
        <para>
         SSPI/GSSAPI authentication support
        </para>
+
+       <para>
+        This adds native Security Service Provider Interface (SSPI) for
+        Windows.
+       </para>
       </listitem>
 
       <listitem>
@@ -147,58 +183,81 @@ do it for earlier branch release files.
        </para>
 
        <para>
-        Autovacuum is now considered mature enough to be enabled by default.
+        This allows multiple vacuums to run concurrently, meaning
+        vacuuming of a large table will not prevent smaller tables from
+        being vacuumed at the same time. Autovacuum is now considered
+        mature and thus enabled by default.
        </para>
       </listitem>
 
       <listitem>
        <para>
-        The entire <productname>PostgreSQL</productname> system can
-        now be compiled with Microsoft Visual C++
+        The backend database server can now be compiled with
+        <productname>Microsoft Visual C++</>
        </para>
 
        <para>
-        This will improve the ability of Windows-based developers to
-        contribute to the project.  Windows executables made with Visual C++
-        may also have better stability and performance than those made with
-        other tool sets.
+         Windows executables made with Visual C++ might have better
+         stability and performance than those made with other tool sets.
+         Development and debugging tools familiar to Windows developers
+         will also work.
        </para>
       </listitem>
 
     </itemizedlist>
 
-    Major performance improvements in this release include:
+    Major performance improvements are listed below. Fortunately, most
+    of these enhancements are automatic and require user changes or
+    tuning:
 
     <itemizedlist>
 
       <listitem>
        <para>
-        Asynchronous commit option to allow transactions to be reported
-        committed before they have actually been flushed to disk
+        Asynchronous commit option allows transactions to be committed
+        but on-disk changes to be delayed
        </para>
 
        <para>
-        This would not, of course, be acceptable if the client takes some
-        critical external action on the assumption that the transaction
-        will be remembered; but for certain applications, it is an acceptable
-        risk for some or all transactions to use this mode.  Unlike existing
-        options such as <varname>fsync</varname>, asynchronous commit does
-        not risk database corruption; the worst case is that after a crash,
-        the last few reportedly-committed transactions will not have
-        taken effect.
+        This feature dramatically increases performance for data
+        modification queries. The disadvantage is that because on-disk
+        changes are delayed, if the operating system crashes before data
+        is written to the disk, committed data will be lost. This is
+        useful only for applications that can accept some data loss.
+        Unlike <varname>fsync</varname>, asynchronous commit does not
+        risk database corruption; the worst case is that after an
+        operating system crash the last few reportedly-committed
+        transactions will be missing.
        </para>
       </listitem>
 
       <listitem>
        <para>
-        <quote>Distributed</> checkpoints to spread out the I/O load of a
-        checkpoint
+        <quote>Distributed</> checkpoints prevent I/O spikes during
+        checkpoints
+       </para>
+
+       <para>
+        Previously all modified buffers were forced to disk at
+        checkpoint time, causing an I/O spike and decreasing server
+        performance. This new capability spreads checkpoint activity out
+        between checkpoints, reducing peak I/O usage.
        </para>
       </listitem>
 
       <listitem>
        <para>
-        Heap-Only Tuples (HOT) to reduce overhead of updates
+        Heap-Only Tuples (<acronym>HOT</>) improves <command>UPDATE</>
+        space usage
+       </para>
+
+       <para>
+        To allow high concurrency <productname>PostgreSQL</> retains old
+        versions of updated rows. Previously only <command>VACUUM</>
+        could reuse space taken by dead rows. With <acronym>HOT</> dead
+        row space can be reused at the time of <command>UPDATE</> or
+        <command>INSERT</>. This allows for more consistent performance.
+        <acronym>HOT</> also improved deleted row space reuse.
        </para>
       </listitem>
 
@@ -207,41 +266,66 @@ do it for earlier branch release files.
         Just-in-time background writer strategy to improve disk write
         efficiency
        </para>
+
+       <para>
+        This basically makes the background writer self-tuning.
+       </para>
+
       </listitem>
 
       <listitem>
        <para>
-        Reduction of on-disk data size through reducing both per-tuple
-        and per-field overheads
+        Reduction of both per-field and per-row storage requirements
+       </para>
+
+       <para>
+        Variable-length data types with data values less then 128 bytes
+        will see a decrease of 3-6 bytes. For example, two
+        <type>CHAR(1)</type> fields now take 4 bytes instead of 16. Rows
+        are also 4 bytes shorter.
        </para>
       </listitem>
 
       <listitem>
        <para>
-        Efficiency improvements for large sequential scans, including
-        prevention of cache flushing and <quote>piggybacking</quote> to let
-        concurrent scans read the table only once
+        Prevent large sequential scans from forcing out more frequently
+        used cached pages
        </para>
       </listitem>
 
       <listitem>
        <para>
-        Top-N sorting
+        Allow large sequential scans to use cached pages from other
+        concurrent sequential scans
+       </para>
+
+       <para>
+        This is accomplished by starting the new sequential scan in the
+        middle of the table (where the other sequential scan is already
+        in-progress) and wrapping around to the beginning to finish.
        </para>
       </listitem>
 
       <listitem>
        <para>
-        Lazy XID assignment to reduce the cost of read-only transactions
+        Allow <literal>ORDER BY ... LIMIT</> to be done without sorting
        </para>
 
        <para>
-        For applications in which there are a large number of read-only
-        transactions, this helps not only by reducing overhead for the
-        transactions themselves, but by reducing overhead that's driven
-        by the rate of XID consumption; notably, reducing contention for
-        transaction log buffers and reducing the frequency of
-        anti-wraparound vacuuming.
+        This is done by scanning the table and using a filter to find
+        the few requested rows, rather than sorting the entire table.
+       </para>
+      </listitem>
+
+      <listitem>
+       <para>
+        Use pseudo-transaction ids in read-only transactions
+       </para>
+
+       <para>
+        This reduces transaction overhead for read-only transactions,
+        and reduces the need for vacuuming for transaction id
+        wrap-around.
        </para>
       </listitem>
 
@@ -268,8 +352,8 @@ do it for earlier branch release files.
 
       <listitem>
        <para>
-        <filename>contrib/tsearch2</> features have been absorbed into
-        the core, with some syntax changes
+        <filename>contrib/tsearch2</> features have been moved into
+        the core server, with some minor syntax changes
        </para>
 
        <para>
@@ -279,23 +363,23 @@ do it for earlier branch release files.
 
       <listitem>
        <para>
-        Casts to <type>text</type> that formerly occurred implicitly may now
-        need to be written explicitly
+        Queries that previously automatically cast values to
+        <type>TEXT</type> might now need explicit casts
        </para>
 
        <para>
-        Data types other than <type>char</> and <type>varchar</> are no
-        longer implicitly castable to <type>text</>, except in the limited
-        case of a <literal>||</> (concatenation) operator whose other
-        input is textual.  While this will require explicit casts in a
-        few queries that didn't need them before, the elimination of
-        surprising interpretations justifies it.
+        Data types other than <type>CHAR</> and <type>VARCHAR</> no
+        longer automatically cast to <type>TEXT</>, except in the
+        limited case of concatenation (<literal>||</>) where the other
+        input is textual. While this change will require additional
+        casts for some queries it also eliminates some unusual
+        behavior.
        </para>
       </listitem>
 
       <listitem>
        <para>
-        Numerous changes in administrator-only configuration parameters
+        Numerous changes in administrative server parameters
        </para>
 
        <para>
@@ -310,9 +394,10 @@ do it for earlier branch release files.
         <varname>track_activities</>.
         <varname>stats_block_level</> and <varname>stats_row_level</>
         are merged into <varname>track_counts</>.
-        <varname>archive_command</> changed meaning slightly: you must now set
-        <varname>archive_mode</> to <literal>on</> as well to enable archiving.
-        The default autovacuum-related settings changed.
+        Previously <varname>archive_command</> controlled whether
+        archiving was performed. Now a new boolean configuration
+        parameter, <varname>archive_mode</>, controls this. Autovacuum's
+        default settings have changed.
        </para>
       </listitem>
 
@@ -321,121 +406,126 @@ do it for earlier branch release files.
         Commenting out a parameter in <filename>postgresql.conf</> now
         causes it to revert to its default value
        </para>
+
+       <para>
+        Previously commenting out a value kept the value unchanged until
+        the next server restart.
+       </para>
       </listitem>
 
       <listitem>
        <para>
-        <literal>ARRAY(SELECT ...)</literal> now returns an empty array,
-        rather than a NULL, when the sub-select returns zero rows
+        <literal>ARRAY(SELECT ...)</literal>, where <command>SELECT</>
+        returns no rows, now returns an empty array, rather than NULL
        </para>
       </listitem>
 
       <listitem>
        <para>
-        <literal>ORDER BY ... USING</> <replaceable>operator</>
-        will now be rejected if the <replaceable>operator</> is not a
-        less-than or greater-than member of some btree operator class
+        <literal>ORDER BY ... USING</> <replaceable>operator</> now must
+        use a less-than or greater-than <replaceable>operator</> that is
+        defined in a btree operator class
        </para>
 
        <para>
-        This prevents less-than-sane behavior that formerly ensued if an
-        operator that doesn't actually define a proper sort ordering was
-        specified.
+        This restriction was added to prevent unexpected results.
        </para>
       </listitem>
 
       <listitem>
        <para>
-        The array type associated with a type named <quote>foo</quote>
-        is not necessarily named <quote>_foo</quote> anymore
+        The array name for a base data type is no longer required to
+        be the data type name with an underscore prefix
        </para>
 
        <para>
         The old naming convention is still honored when possible, but
-        client code should migrate away from depending on it.
+        client code should no longer depending on it.
        </para>
       </listitem>
 
       <listitem>
        <para>
-        By default, non-superuser database owners can now instantiate trusted
-        procedural languages in their databases
+        Non-superuser database owners now have privileges to add trusted
+        procedural languages in their databases by default
        </para>
 
        <para>
         While this is reasonably safe, some administrators may wish to
-        revoke the privilege.
+        revoke the privilege. It is controlled by
+        <structname>pg_pltemplate</>.<structfield>tmpldbacreate</>.
        </para>
       </listitem>
 
       <listitem>
        <para>
-        The effects of <command>SET LOCAL</command> now persist until
-        the end of the current top transaction, unless rolled back
+        <command>SET LOCAL</command> changes now persist until
+        the end of the top-most transaction, unless rolled back
        </para>
 
        <para>
-        In 8.0 through 8.2, <command>SET LOCAL</command>'s
-        effects disappeared at subtransaction commit, leading to behavior
-        that made little sense at the SQL level (one would not normally
-        expect <command>RELEASE</> to do such a thing).
+        Previously <command>SET LOCAL</command>'s effects reverted
+        during subtransaction commit and <command>RELEASE</>.
        </para>
       </listitem>
 
       <listitem>
        <para>
-        Commands that are disallowed in transaction blocks are now disallowed
-        in multiple-statement query strings, too
+        Commands that are disallowed in transaction blocks are now also
+        disallowed in multiple-statement query strings
        </para>
 
        <para>
         For example, <literal>BEGIN; DROP DATABASE; COMMIT</> will now be
-        rejected even if submitted as a single Query message.  This was always
-        quite unsafe, but the <function>PreventTransactionChain</function>
-        test failed to detect it.
+        rejected even if submitted as a single query message.
        </para>
       </listitem>
 
       <listitem>
        <para>
-        Additional checks for invalidly-encoded multibyte strings
+        Add additional checks for invalidly-encoded multibyte strings
        </para>
 
        <para>
-        Some cases that might formerly have allowed invalid data to
-        enter the database will now be rejected.  In particular, the
-        <function>chr()</function> function changed behavior.
+        For example, <function>chr()</function> has additional checks.
        </para>
       </listitem>
 
       <listitem>
        <para>
-        <function>convert()</function> family of functions changed behavior
+        <function>convert()</function> encoding has changed behavior
        </para>
 
        <para>
-        Strings that are not in the database's native encoding are now
-        represented as type <type>bytea</> rather than type <type>text</>.
+        <type>bytea</> is now used for strings that do not match the
+        server encoding, and <function>convert_from</> and
+        <function>convert_to</> have been added for consistency.
        </para>
       </listitem>
 
       <listitem>
        <para>
-        Minor security restrictions added to database-size inquiry functions
-        and some contrib functions
+        Restrict object size functions to users who have reasonable
+        permissions to view such information
+       </para>
+
+       <para>
+        For example, database size now requires <literal>CONNECT</>
+        permission, and tablespaces size requires <literal>CREATE</>
+        permission.
        </para>
       </listitem>
 
       <listitem>
        <para>
-        C code that manipulates variable-length datums will need changes
+        New C macros for handling variable-length data values
        </para>
 
        <para>
-        The new <function>SET_VARSIZE()</> macro <emphasis>must</> be used
-        to set the length word of a generated datum.  Also, it may be
-        necessary to <quote>detoast</quote> input varlena datums in cases
-        where no toasting could have happened before.
+        The new <function>SET_VARSIZE()</> macro <emphasis>must</> be
+        used to set the length of generated values. Also, it might be
+        necessary to expand (<quote>de-TOAST</quote>) input values in
+        additional places.
        </para>
       </listitem>