diff options
| -rw-r--r-- | doc/src/sgml/release.sgml | 72 |
1 files changed, 39 insertions, 33 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: @@ -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> |