|
1 | | -<!-- $PostgreSQL: pgsql/doc/src/sgml/plpgsql.sgml,v 1.143 2009/09/29 20:05:29 tgl Exp $ --> |
| 1 | +<!-- $PostgreSQL: pgsql/doc/src/sgml/plpgsql.sgml,v 1.144 2009/11/05 16:58:36 tgl Exp $ --> |
2 | 2 |
|
3 | 3 | <chapter id="plpgsql"> |
4 | 4 | <title><application>PL/pgSQL</application> - <acronym>SQL</acronym> Procedural Language</title> |
|
135 | 135 | and <type>anyenum</>. The actual |
136 | 136 | data types handled by a polymorphic function can vary from call to |
137 | 137 | call, as discussed in <xref linkend="extend-types-polymorphic">. |
138 | | - An example is shown in <xref linkend="plpgsql-declaration-aliases">. |
| 138 | + An example is shown in <xref linkend="plpgsql-declaration-parameters">. |
139 | 139 | </para> |
140 | 140 |
|
141 | 141 | <para> |
|
163 | 163 |
|
164 | 164 | <para> |
165 | 165 | Specific examples appear in |
166 | | - <xref linkend="plpgsql-declaration-aliases"> and |
| 166 | + <xref linkend="plpgsql-declaration-parameters"> and |
167 | 167 | <xref linkend="plpgsql-statements-returning">. |
168 | 168 | </para> |
169 | 169 | </sect2> |
@@ -353,8 +353,8 @@ user_id CONSTANT integer := 10; |
353 | 353 | </programlisting> |
354 | 354 | </para> |
355 | 355 |
|
356 | | - <sect2 id="plpgsql-declaration-aliases"> |
357 | | - <title>Aliases for Function Parameters</title> |
| 356 | + <sect2 id="plpgsql-declaration-parameters"> |
| 357 | + <title>Declaring Function Parameters</title> |
358 | 358 |
|
359 | 359 | <para> |
360 | 360 | Parameters passed to functions are named with the identifiers |
@@ -401,7 +401,7 @@ $$ LANGUAGE plpgsql; |
401 | 401 | These two examples are not perfectly equivalent. In the first case, |
402 | 402 | <literal>subtotal</> could be referenced as |
403 | 403 | <literal>sales_tax.subtotal</>, but in the second case it could not. |
404 | | - (Had we attached a label to the block, <literal>subtotal</> could |
| 404 | + (Had we attached a label to the inner block, <literal>subtotal</> could |
405 | 405 | be qualified with that label, instead.) |
406 | 406 | </para> |
407 | 407 | </note> |
@@ -532,6 +532,38 @@ $$ LANGUAGE plpgsql; |
532 | 532 | </para> |
533 | 533 | </sect2> |
534 | 534 |
|
| 535 | + <sect2 id="plpgsql-declaration-alias"> |
| 536 | + <title><literal>ALIAS</></title> |
| 537 | + |
| 538 | +<synopsis> |
| 539 | +<replaceable>newname</> ALIAS FOR <replaceable>oldname</>; |
| 540 | +</synopsis> |
| 541 | + |
| 542 | + <para> |
| 543 | + The <literal>ALIAS</> syntax is more general than is suggested in the |
| 544 | + previous section: you can declare an alias for any variable, not just |
| 545 | + function parameters. The main practical use for this is to assign |
| 546 | + a different name for variables with predetermined names, such as |
| 547 | + <varname>NEW</varname> or <varname>OLD</varname> within |
| 548 | + a trigger procedure. |
| 549 | + </para> |
| 550 | + |
| 551 | + <para> |
| 552 | + Examples: |
| 553 | +<programlisting> |
| 554 | +DECLARE |
| 555 | + prior ALIAS FOR old; |
| 556 | + updated ALIAS FOR new; |
| 557 | +</programlisting> |
| 558 | + </para> |
| 559 | + |
| 560 | + <para> |
| 561 | + Since <literal>ALIAS</> creates two different ways to name the same |
| 562 | + object, unrestricted use can be confusing. It's best to use it only |
| 563 | + for the purpose of overriding predetermined names. |
| 564 | + </para> |
| 565 | + </sect2> |
| 566 | + |
535 | 567 | <sect2 id="plpgsql-declaration-type"> |
536 | 568 | <title>Copying Types</title> |
537 | 569 |
|
@@ -664,39 +696,6 @@ SELECT merge_fields(t.*) FROM table1 t WHERE ... ; |
664 | 696 | structure on-the-fly. |
665 | 697 | </para> |
666 | 698 | </sect2> |
667 | | - |
668 | | - <sect2 id="plpgsql-declaration-renaming-vars"> |
669 | | - <title><literal>RENAME</></title> |
670 | | - |
671 | | -<synopsis> |
672 | | -RENAME <replaceable>oldname</replaceable> TO <replaceable>newname</replaceable>; |
673 | | -</synopsis> |
674 | | - |
675 | | - <para> |
676 | | - Using the <literal>RENAME</literal> declaration you can change the |
677 | | - name of a variable, record or row. This is primarily useful if |
678 | | - <varname>NEW</varname> or <varname>OLD</varname> should be |
679 | | - referenced by another name inside a trigger procedure. See also |
680 | | - <literal>ALIAS</literal>. |
681 | | - </para> |
682 | | - |
683 | | - <para> |
684 | | - Examples: |
685 | | -<programlisting> |
686 | | -RENAME id TO user_id; |
687 | | -RENAME this_var TO that_var; |
688 | | -</programlisting> |
689 | | - </para> |
690 | | - |
691 | | - <note> |
692 | | - <para> |
693 | | - <literal>RENAME</literal> appears to be broken as of |
694 | | - <productname>PostgreSQL</> 7.3. Fixing this is of low priority, |
695 | | - since <literal>ALIAS</literal> covers most of the practical uses |
696 | | - of <literal>RENAME</literal>. |
697 | | - </para> |
698 | | - </note> |
699 | | - </sect2> |
700 | 699 | </sect1> |
701 | 700 |
|
702 | 701 | <sect1 id="plpgsql-expressions"> |
|
0 commit comments