Add a compatibility note about plpgsql's treatment of SELECT INTO rec.fld

when fld is of composite type.  Per discussion of bug #5644 from Valentine
Gogichashvili.

diff --git a/doc/src/sgml/release-9.0.sgml b/doc/src/sgml/release-9.0.sgml
index 7bfdf1419b09a33f20dc6bfacaf5d303df4ee2cd..6d29ddd1e935f888696855ed63ebdcc21ca867ba 100644 (file)
--- a/doc/src/sgml/release-9.0.sgml
+++ b/doc/src/sgml/release-9.0.sgml
@@ -1,4 +1,4 @@
-<!-- $PostgreSQL: pgsql/doc/src/sgml/release-9.0.sgml,v 2.55 2010/09/01 15:14:42 tgl Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/release-9.0.sgml,v 2.56 2010/09/15 17:45:57 tgl Exp $ -->
 
  <sect1 id="release-9-0">
   <title>Release 9.0</title>
@@ -434,6 +434,31 @@
      </para>
     </listitem>
 
+    <listitem>
+     <para>
+      PL/pgSQL now treats selection into composite fields more consistently
+      (Tom Lane)
+     </para>
+
+     <para>
+      Formerly, a statement like
+      <literal>SELECT ... INTO <replaceable>rec</>.<replaceable>fld</> FROM ...</literal>
+      was treated as a scalar assignment even if the record field
+      <replaceable>fld</> was of composite type.  Now it is treated as a
+      record assignment, the same as when the <literal>INTO</> target is a
+      regular variable of composite type.  So the values to be assigned to the
+      field's subfields should be written as separate columns of the
+      <command>SELECT</> list, not as a <literal>ROW(...)</> construct as in
+      previous versions.
+     </para>
+
+     <para>
+      If you need to do this in a way that will work in both 9.0 and previous
+      releases, you can write something like
+      <literal><replaceable>rec</>.<replaceable>fld</> := ROW(...) FROM ...</literal>.
+     </para>
+    </listitem>
+
     <listitem>
      <para>
       Remove PL/pgSQL's <literal>RENAME</> declaration (Tom Lane)