|
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