Update 9.4 release notes for commits through today.

Add entries for recent changes, including noting the JSONB format change
and the recent timezone data changes.  We should remove those two items
before 9.4 final: the JSONB change will be of no interest in the long
run, and it's not normally our habit to mention timezone updates in
major-release notes.  But it seems important to document them temporarily
for beta testers.

I failed to resist the temptation to wordsmith a couple of existing
entries, too.
This commit is contained in:
Tom Lane 2014-10-05 14:14:04 -04:00
parent d0410d6603
commit f706f2c1a0

View File

@ -7,7 +7,8 @@
<note> <note>
<title>Release Date</title> <title>Release Date</title>
<simpara>2014-??-??</simpara> <simpara>2014-??-??</simpara>
<simpara>Current as of 2014-08-17</simpara> <simpara>Current as of 2014-10-05</simpara>
<!-- Be sure to remove "delta from 9.4beta" items below before final! -->
</note> </note>
<sect2> <sect2>
@ -89,6 +90,22 @@
<itemizedlist> <itemizedlist>
<!-- delta from 9.4beta2, be sure to remove before final: -->
<listitem>
<para>
Change on-disk format of <type>jsonb</> data
(Heikki Linnakangas and Tom Lane)
</para>
<para>
The on-disk representation was changed after 9.4beta2 to improve
efficiency. <application>pg_upgrade</> will refuse to upgrade any
9.4beta1 or 9.4beta2 database containing <type>jsonb</> columns; you
will need to use <application>pg_dumpall</> instead to migrate such
databases.
</para>
</listitem>
<listitem> <listitem>
<para> <para>
Tighten checks for multidimensional <link Tighten checks for multidimensional <link
@ -224,18 +241,6 @@
</para> </para>
</listitem> </listitem>
<listitem>
<para>
Writable foreign data wrappers must return all columns when the foreign
table has an <literal>AFTER ROW</> trigger (Noah Misch)
</para>
<para>
Previously, foreign tables never had triggers, and
the <literal>RETURNING</> clause alone dictated the columns required.
</para>
</listitem>
<listitem> <listitem>
<para> <para>
Rename <link linkend="SQL-EXPLAIN"><command>EXPLAIN Rename <link linkend="SQL-EXPLAIN"><command>EXPLAIN
@ -265,6 +270,22 @@
</para> </para>
</listitem> </listitem>
<listitem>
<para>
Foreign data wrappers that support updating foreign tables must
consider the possible presence of <literal>AFTER ROW</> triggers
(Noah Misch)
</para>
<para>
When an <literal>AFTER ROW</> trigger is present, all columns of the
table must be returned by updating actions, since the trigger might
inspect any or all of them. Previously, foreign tables never had
triggers, so the FDW might optimize away fetching columns not mentioned
in the <literal>RETURNING</> clause (if any).
</para>
</listitem>
<listitem> <listitem>
<para> <para>
Prevent <link Prevent <link
@ -389,6 +410,27 @@
</para> </para>
</listitem> </listitem>
<!-- delta from 9.4beta2, be sure to remove before final: -->
<listitem>
<para>
Update time zone data files to tzdata release 2014h for DST law
changes in Russia and elsewhere
</para>
<para>
This change is more significant than most time zone updates because
many Russian zone abbreviations are changing meaning, including IRKT,
KRAT, MAGT, MSK, NOVT, OMST, SAKT, VLAT, YAKT, and YEKT. Also, IANA
has formally recognized abbreviations of the form
A<replaceable>x</>ST/A<replaceable>x</>DT for Australian timezones,
so adopt those names as part of the <quote>Default</> abbreviation
set in <productname>PostgreSQL</>. The <quote>Australia</>
abbreviation set now need be selected only if it's desired to use
historical abbreviations that conflict with abbreviations commonly
used elsewhere, such as EST or SAST.
</para>
</listitem>
</itemizedlist> </itemizedlist>
</sect2> </sect2>
@ -1099,6 +1141,14 @@
</para> </para>
</listitem> </listitem>
<listitem>
<para>
Ensure that <link linkend="SQL-SELECT"><literal>SELECT ... FOR UPDATE
NOWAIT</></link> does not wait in corner cases involving
already-concurrently-updated tuples (Craig Ringer and Thomas Munro)
</para>
</listitem>
</itemizedlist> </itemizedlist>
</sect3> </sect3>
@ -1257,11 +1307,9 @@
<listitem> <listitem>
<para> <para>
Allow moving groups of objects from one tablespace to another Allow moving groups of objects from one tablespace to another
using <literal>ALL IN TABLESPACE ... SET TABLESPACE</> with using the <literal>ALL IN TABLESPACE ... SET TABLESPACE</> form of
<link linkend="SQL-ALTERTABLE"><command>ALTER TABLE</></link> <xref linkend="SQL-ALTERTABLE">, <xref linkend="SQL-ALTERINDEX">, or
<link linkend="SQL-ALTERINDEX"><command>ALTER INDEX</></link> and <xref linkend="SQL-ALTERMATERIALIZEDVIEW"> (Stephen Frost)
<link linkend="SQL-ALTERMATERIALIZEDVIEW"><command>ALTER MATERIALIZED VIEW</></link>
(Stephen Frost)
</para> </para>
</listitem> </listitem>
@ -2498,9 +2546,21 @@
</para> </para>
<para> <para>
This allows monitoring tools to only fetch query text for newly This allows monitoring tools to fetch query text only for
created entries, improving performance for repeated querying of the just-created entries, improving performance during repeated querying
statistics. of the statistics.
</para>
</listitem>
<listitem>
<para>
Make <application>pg_stat_statements</> ignore <command>DEALLOCATE</>
commands (Fabien Coelho)
</para>
<para>
It already ignored <command>PREPARE</>, as well as planning time in
general, so this seems more consistent.
</para> </para>
</listitem> </listitem>