From 7f2f798b30b53dc24bee78ec4e1f3c2d0d987de0 Mon Sep 17 00:00:00 2001
From: Tom Lane <tgl@sss.pgh.pa.us>
Date: Sun, 19 Apr 2009 15:49:34 +0000
Subject: [PATCH] Mention as a potential incompatibility the fact that SELECT
 DISTINCT, UNION, etc are no longer guaranteed to produce sorted output; per
 gripe from Ian Barwick.  Also improve the release note entries about
 to_timestamp(), per Brendan Jurd.

---
 doc/src/sgml/release.sgml | 76 +++++++++++++++++++++------------------
 1 file changed, 41 insertions(+), 35 deletions(-)

diff --git a/doc/src/sgml/release.sgml b/doc/src/sgml/release.sgml
index f8e5849195a..b487905c256 100644
--- a/doc/src/sgml/release.sgml
+++ b/doc/src/sgml/release.sgml
@@ -1,4 +1,4 @@
-<!-- $PostgreSQL: pgsql/doc/src/sgml/release.sgml,v 1.629 2009/04/18 00:01:01 momjian Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/release.sgml,v 1.630 2009/04/19 15:49:34 tgl Exp $ -->
 <!--
 
 Typical markup:
@@ -331,6 +331,39 @@ do it for earlier branch release files.
 
     <itemizedlist>
 
+     <listitem>
+      <para>
+       Change <command>TRUNCATE</> and <command>LOCK</> to
+       apply to child tables of the specified table(s) (Peter)
+      </para>
+
+      <para>
+       These commands now accept an <literal>ONLY</> option that prevents
+       processing child tables; this option must be used if the old
+       behavior is needed.
+      </para>
+     </listitem>
+
+     <listitem>
+      <para>
+       <command>SELECT DISTINCT</> and
+       <literal>UNION</>/<literal>INTERSECT</>/<literal>EXCEPT</>
+       no longer always produce sorted output (Tom)
+      </para>
+
+      <para>
+       Previously, these types of queries always removed duplicate rows
+       by means of Sort/Unique processing (i.e., sort then remove adjacent
+       duplicates).  Now they can be implemented by hashing, which will not
+       produce sorted output.  If an application relied on the output being
+       in sorted order, the recommended fix is to add an <literal>ORDER BY</>
+       clause.  As a short-term workaround, the previous behavior can be
+       restored by disabling <literal>enable_hashagg</>, but that is a very
+       performance-expensive fix.  <literal>SELECT DISTINCT ON</> never uses
+       hashing, however, so its behavior is unchanged.
+      </para>
+     </listitem>
+
      <listitem>
       <para>
        Force child tables to inherit <literal>CHECK</> constraints from parents
@@ -345,19 +378,6 @@ do it for earlier branch release files.
       </para>
      </listitem>
 
-     <listitem>
-      <para>
-       Change <command>TRUNCATE</> and <command>LOCK</> to
-       apply to child tables of the specified table(s) (Peter)
-      </para>
-
-      <para>
-       These commands now accept an <literal>ONLY</> option that prevents
-       processing child tables; this option must be used if the old
-       behavior is needed.
-      </para>
-     </listitem>
-
      <listitem>
       <para>
        Disallow negative <literal>LIMIT</> or <literal>OFFSET</>
@@ -512,6 +532,12 @@ do it for earlier branch release files.
         to more consistently report errors for invalid input (Brendan
         Jurd)
        </para>
+
+       <para>
+        Previous versions would often ignore or silently misread input
+        that did not match the format string.  Such cases will now
+        result in an error.
+       </para>
       </listitem>
 
       <listitem>
@@ -528,21 +554,6 @@ do it for earlier branch release files.
        </para>
       </listitem>
 
-      <listitem>
-       <para>
-        Require <function>to_timestamp()</> input to match
-        meridian (<literal>AM</>/<literal>PM</>) and era
-        (<literal>BC</>/<literal>AD</>) format designations with
-        respect to presence of periods
-        (Brendan Jurd)
-       </para>
-
-       <para>
-        For example, input value <literal>AD</> now does not match
-        format string <literal>A.D.</>.
-       </para>
-      </listitem>
-
      </itemizedlist>
 
     </sect4>
@@ -584,12 +595,7 @@ do it for earlier branch release files.
 
       <para>
        This means that these types of queries no longer automatically
-       produce sorted output.  The recommended response is to add an
-       <literal>ORDER BY</> clause if needed.  As a short-term workaround,
-       the previous behavior can be restored by
-       disabling <literal>enable_hashagg</>, but that is a very
-       performance-expensive fix. <literal>SELECT DISTINCT ON</> never
-       uses hashing, however, so its behavior is unchanged.
+       produce sorted output.
       </para>
      </listitem>