|
1 |
| -<!-- $PostgreSQL: pgsql/doc/src/sgml/release-9.0.sgml,v 2.55 2010/09/01 15:14:42 tgl Exp $ --> |
| 1 | +<!-- $PostgreSQL: pgsql/doc/src/sgml/release-9.0.sgml,v 2.56 2010/09/15 17:45:57 tgl Exp $ --> |
2 | 2 |
|
3 | 3 | <sect1 id="release-9-0">
|
4 | 4 | <title>Release 9.0</title>
|
|
434 | 434 | </para>
|
435 | 435 | </listitem>
|
436 | 436 |
|
| 437 | + <listitem> |
| 438 | + <para> |
| 439 | + PL/pgSQL now treats selection into composite fields more consistently |
| 440 | + (Tom Lane) |
| 441 | + </para> |
| 442 | + |
| 443 | + <para> |
| 444 | + Formerly, a statement like |
| 445 | + <literal>SELECT ... INTO <replaceable>rec</>.<replaceable>fld</> FROM ...</literal> |
| 446 | + was treated as a scalar assignment even if the record field |
| 447 | + <replaceable>fld</> was of composite type. Now it is treated as a |
| 448 | + record assignment, the same as when the <literal>INTO</> target is a |
| 449 | + regular variable of composite type. So the values to be assigned to the |
| 450 | + field's subfields should be written as separate columns of the |
| 451 | + <command>SELECT</> list, not as a <literal>ROW(...)</> construct as in |
| 452 | + previous versions. |
| 453 | + </para> |
| 454 | + |
| 455 | + <para> |
| 456 | + If you need to do this in a way that will work in both 9.0 and previous |
| 457 | + releases, you can write something like |
| 458 | + <literal><replaceable>rec</>.<replaceable>fld</> := ROW(...) FROM ...</literal>. |
| 459 | + </para> |
| 460 | + </listitem> |
| 461 | + |
437 | 462 | <listitem>
|
438 | 463 | <para>
|
439 | 464 | Remove PL/pgSQL's <literal>RENAME</> declaration (Tom Lane)
|
|