Subject: Release notes patch #2

From: Josh Berkus <[email-masked]>
Date: Wed, 16 Jun 2010 10:10:40 -0700

Bruce,

Still working on the release notes, another interim patch to prevent 
conflicts.  Are you going after the two patch authors where we need 
clarification on their patches?

-- 
                                   -- Josh Berkus
                                      PostgreSQL Experts Inc.
                                      http://www.pgexperts.com
Index: release-9.0.sgml
===================================================================
RCS file: /projects/cvsroot/pgsql/doc/src/sgml/release-9.0.sgml,v
retrieving revision 2.31
diff -c -r2.31 release-9.0.sgml
*** release-9.0.sgml	14 Jun 2010 02:18:43 -0000	2.31
--- release-9.0.sgml	16 Jun 2010 17:07:58 -0000
***************
*** 108,114 ****
        Add support for compiling on <link
        linkend="install-win32-full">64-bit
        <productname>Windows</></link> and running in 64-bit
!       mode
       </para>
      </listitem>
  
--- 108,114 ----
        Add support for compiling on <link
        linkend="install-win32-full">64-bit
        <productname>Windows</></link> and running in 64-bit
!       mode.
       </para>
      </listitem>
  
***************
*** 133,145 ****
    <para>CURRENT AS OF 2010-06-03</para>
  
    <para>
!    A dump/restore using <application>pg_dump</application> is
!    required for those wishing to migrate data from any previous
     release.
    </para>
  
    <para>
!    Observe the following incompatibilities:
    </para>
  
    <sect3>
--- 133,149 ----
    <para>CURRENT AS OF 2010-06-03</para>
  
    <para>
!    A dump/restore using <application>pg_dump</application>
!    or use of <application>pg_upgrade</application> is required 
!    for those wishing to migrate data from any previous
     release.
    </para>
  
    <para>
!    Version 9.0 contains a number of changes which selectively break backwards compatibility
!    in order to support new features and code quality improvements.  Particularly, users
!    who make extensive use of PL/pgSQL and/or PITR and Warm Standby should test their
!    solutions for breakage.  Observe the following incompatibilities:
    </para>
  
    <sect3>
***************
*** 488,493 ****
--- 492,503 ----
         linkend="guc-geqo-seed">geqo_seed</link> to randomize
         the starting value of the random plan generator.
        </para>
+ 
+       <para>
+        This gives GEQO query response times and resource usage
+        repeatability and predictability.
+       </para>
+ 
       </listitem>
  
       <listitem>
***************
*** 623,628 ****
--- 633,643 ----
         name</link>, which is displayed in
         <structname>pg_stat_activity</> (Dave Page)
        </para>
+ 
+       <para>
+ 	This allows DBAs to characterize database traffic 
+ 	and troubleshoot problems by source application.
+       </para>
       </listitem>
  
       <listitem>
***************
*** 688,694 ****
--- 703,713 ----
         in the new <structname>pg_db_role_setting</> system table. A new
         <application>psql</> <literal>\drds</> command shows these settings.
         Backwards-compatible system views do not show this information.
+        The primary use of this feature is setting schema 
+        <link linkend="guc-search_path"><varname>search_path</varname></link>.
        </para>
+ 
+ 
       </listitem>
  
       <listitem>
***************
*** 722,727 ****
--- 741,752 ----
         Log changed parameter values when <filename>postgresql.conf</> is
         reloaded (Peter Eisentraut)
        </para>
+ 
+       <para>
+        This lets DBAs and security staff to audit when database settings
+        were changed.
+       </para>
+ 
       </listitem>
  
       <listitem>
***************
*** 795,800 ****
--- 820,831 ----
       </para>
  
       <para>
+       For drivers which support this feature, this saves an entire 
+       round-trip to the client, allowing result counts and pagination
+       to be calculated without a second <command>COUNT</command> query.
+      </para>
+ 
+      <para>
        <application>psql</> does not display these counts.
       </para>
      </listitem>
***************
*** 909,915 ****
        <para>
         Such operations either complete fully or are rolled back, so
         <acronym>WAL</> archiving can be skipped, unless running in continuous
!        archiving mode.
        </para>
       </listitem>
  
--- 940,946 ----
        <para>
         Such operations either complete fully or are rolled back, so
         <acronym>WAL</> archiving can be skipped, unless running in continuous
!        archiving mode.  This reduces I/O overhead and improves performance.
        </para>
       </listitem>
  
***************
*** 1274,1279 ****
--- 1305,1317 ----
        <function>PQescapeByteaConn()</> now uses the hex format
        for <productname>PostgreSQL</> 9.0 servers.
       </para>
+ 
+      <para>
+       The new hex format will be directly compatible with more applications
+       which use binary data, allowing them to store and retrieve
+       it without conversion.
+      </para>
+ 
      </listitem>
  
      <listitem>
***************
*** 1417,1423 ****
        <para>
         For example, this is now supported, <literal>array_agg(a ORDER BY
         b)</>. This is useful for aggregates where the order of values is
!        significant.
        </para>
       </listitem>
  
--- 1455,1462 ----
        <para>
         For example, this is now supported, <literal>array_agg(a ORDER BY
         b)</>. This is useful for aggregates where the order of values is
!        significant, and eliminates the need to have a subquery for
!        the ordering.
        </para>
       </listitem>

---

From: Bruce Momjian <[email-masked]>
Date: Wed, 16 Jun 2010 14:30:30 -0400 (EDT)

> clarification on their patches?

Thanks!   Applied.

-- 
  Bruce Momjian  <[email-masked]>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + None of us is going to be here forever. +