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.

1 files changed, 38 insertions, 32 deletions

diff --git a/doc/src/sgml/release.sgml b/doc/src/sgml/release.sgml
index da41e5b8a2..ea6cbf095a 100644
--- a/doc/src/sgml/release.sgml
+++ b/doc/src/sgml/release.sgml
@@ -333,28 +333,48 @@ do it for earlier branch release files.
 
      <listitem>
       <para>
-       Force child tables to inherit <literal>CHECK</> constraints from parents
-       (Alex Hunsaker, Nikhil Sontakke, Tom)
+       Change <command>TRUNCATE</> and <command>LOCK</> to
+       apply to child tables of the specified table(s) (Peter)
       </para>
 
       <para>
-       Formerly it was possible to drop such a constraint from a child
-       table, allowing rows that violate the constraint to be visible
-       when scanning the parent table.  This was deemed inconsistent,
-       as well as contrary to SQL standard.
+       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>
-       Change <command>TRUNCATE</> and <command>LOCK</> to
-       apply to child tables of the specified table(s) (Peter)
+       <command>SELECT DISTINCT</> and
+       <literal>UNION</>/<literal>INTERSECT</>/<literal>EXCEPT</>
+       no longer always produce sorted output (Tom)
       </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.
+       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
+       (Alex Hunsaker, Nikhil Sontakke, Tom)
+      </para>
+
+      <para>
+       Formerly it was possible to drop such a constraint from a child
+       table, allowing rows that violate the constraint to be visible
+       when scanning the parent table.  This was deemed inconsistent,
+       as well as contrary to SQL standard.
       </para>
      </listitem>
 
@@ -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>