mirrors/postgres
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Mention as a potential incompatibility the fact that SELECT DISTINCT, UNION,

Browse Source 
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.
This commit is contained in:
Tom Lane 2009-04-19 15:49:34 +00:00
parent 6df6846d56
commit 7f2f798b30
1 changed files with 41 additions and 35 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

76
doc/src/sgml/release.sgml
View File

@ -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>